←October→
Mon	Tue	Wed	Thu	Fri	Sat	Sun
		1	2	3	4	5
6	7	8	9	10	11	12
13	14	15	16	17	18	19
20	21	22	23	24	25	26
27	28	29	30	31

This section:

Operations and other mysteries: the subtle business of making technology work... a blog by Andrew Cowie.

The syndication links at top left will give you a feed for the blog as a whole.

blogs > andrew

Sun, 05 Oct 2008

Wine your own business

The things that drive you crazy…

There’s one (and only one) legacy Windows application that we have. We used to run it in VMware, which worked, but that was a pain, looked terrible, and of course was required us to have our copy of Windows 2000 installed there. Decrepit. But far worse, meant we had to use Windows. Yuk. And worst of all to have to keep switching in and out of it. Bah.

Life would be far better if we could run it on Linux under Wine — then it’d just be another app on running on the GNOME desktop and under the control of the window manager. We’d tried seeing if we could get this application to run in Wine a few times over the years; no joy. But somewhere along the line it started noticing list posts from other people reporting positive experiences. So {shrug} I gave it another try this month, and to my intense pleasure it installed cleanly and is running fine. Terrific! The people who hack on Wine are amazing.

So I started working away, only to suddenly realize that the dates were in American mm/dd/yy format. Gah. More searching, but none of the workarounds suggested (mostly to do with manually changing things with Wine’s regedit) seemed to work. Quote a pain.

I had come across a number of references saying that Wine and in turn the program in question would pick up the locale settings provided by your environment. I’d checked that, and tried various combinations. Nothing seemed to work.

I mostly run in en_CA, ie:

$ echo $LANG
en_CA.UTF-8
$

the impact of which you can see by running the locale command:

$ locale
LANG=en_CA.UTF-8
LC_CTYPE="en_CA.UTF-8"
LC_NUMERIC="en_CA.UTF-8"
LC_TIME=en_DK.UTF-8
LC_COLLATE="en_CA.UTF-8"
LC_MONETARY="en_CA.UTF-8"
LC_MESSAGES="en_CA.UTF-8"
LC_PAPER=en_AU.UTF-8
LC_NAME="en_CA.UTF-8"
LC_ADDRESS="en_CA.UTF-8"
LC_TELEPHONE="en_CA.UTF-8"
LC_MEASUREMENT="en_CA.UTF-8"
LC_IDENTIFICATION="en_CA.UTF-8"
LC_ALL=
$

all as one would expect And yet it had no impact on running the program running under Wine [Setting LC_TIME to en_DK is an old trick for people in en locales to get proper 24-hour time formatting; yes, I tried unsetting LC_TIME; I tried dropping the UTF-8 settings; I tried LANG=en_AU. Nothing made any difference].

After a lot more frustration searching around, I finally came across a support article on CodeWeaver’s website that mentioned setting the locale environment variables. Yes yes, I thought, but then I looked more closely. They were setting LC_ALL. Wait a minute. LC_ALL is a special variable that “if set to a non-empty string value, override the values of all the other internationalization variables.” You’re not supposed to set that… certainly one doesn’t set that at login — that’s what LANG is for. I didn’t really expect anything to come of it, but I tried it anyway:

$ env LC_ALL=en_CA.UTF-8 WINEPREFIX="/home/andrew/.wine" wine "C:\Premier12\Myobp.exe"

and ta-da everything worked: I had dd/mm/yy date formatting just like we wanted. Yeay!

I immediately closed everything down and went out for a beer. Sometimes we forget to celebrate those brief moments when things actually work.

But talk about bitterness. I’m not sure if this was a Wine behaviour, a Windows behaviour, or just nonsense code in MYOB. I suspect the latter. But either way, I saw so many posts asking “how can I get the date format to behave under Wine” that I thought I should write about the workaround that did it for us.

AfC

Congratulations Manly!

There really is nothing better than being in your home town at a pub surrounded by several hundred screaming fans when the home side is playing in the Grand Final of its league and then watching them trounce the opposition 40 to 0.

Photo by Brendan Esposito, as presented on the League HQ website

Congratulations to the Manly Sea Eagles for winning the 2008 Rugby League premiership!

AfC

Thu, 11 Sep 2008

Desktop beautification: fix your fonts

One of the nice things about Gentoo Linux is that they tend to leave the upstream defaults alone. This applies to file system locations, build configurations, but also things like preferences across the GNOME Desktop. This is good, in that Gentoo users see the raw upstream, but not entirely optimal in cases where those defaults aren’t as good as they could be or are too generic.

I was pairing with a colleague the other day and they were impressed with how I had things set up — and more to the point my rationales for having done so — and they encouraged me to write about it.

I don’t particularly think I have anything original or novel to say, but in so far as some of us have built up configurations over the years that (for ourselves, at least) improve usability and which define our productivity, I think it’ll be a nice contribution to show others what we’re using and how we got things that way. If you think you know what you’re doing, then I encourage you to write about your customizations — and why you made them. People using commercial distros like Ubuntu and Fedora will justly be able to say “it already looks good” and so if you’re happy you can ignore this, but even in such environments we still often tighten things up to individual taste and so I’m sure you have something to offer.

Anyway, thus begins an occasional series about things I’ve done to beautify my GNOME Desktop on our Gentoo Linux systems.

A few years back I was enjoying a drink with Carl Worth and Keith Packard (free desktop graphics hackers extraordinaire, for those who haven’t met them). Later in the evening Keith leaned over, saw my laptop’s screen, and starting swearing at me: “You need to fix your fonts!” (I was using Luxi or something). So, ok, what do you want me to do? They told me to switch to the Bitstream Vera family as being well sculpted, highly professional, and optimized for screen display. Needless to say I take what these gentlemen say extremely seriously, so did what I was told :).

Like any font or appearances change, for the first day or so it felt a bit odd, but then something shifted and it felt very comfortable. The real give-away that I was on the right track was a few days later when I tried switching back to the old font for the hell of it and recoiled in horror “Gawd that’s ugly!”

Bitstream Vera had done me well for quite some time, but recently I started running into some subtle bugs. One showed up with the weather applet; for whatever reason a few versions ago they changed the string from ‘°’ + ‘C’ to unicode character 0x2103, the symbol for degrees Celsius. I was getting a weird fall back to some horrible looking old bit-mapped font. Yikes (if °C and ℃ don’t look about the same then you’ll see what I mean). No big deal, but it was annoying me.

So I was checking around again to see if there was a different font family I should be using, when I came across the DejaVu. It starts from Bitstream Vera (so the base ASCII characters are all the same and mostly untouched) but adds a ton of hinting corrections, bug fixes, and extensions up in the higher unicode sequences needed by European languages and scientific work. There are also a number of additional faces available. And regular releases (always a good sign). And a different name, per the Bitstream licence terms. When I asked about DejaVu in #gnome-hackers, the answer was “hell yes you should be using it.” Huh. So I switched!

The DejaVu fonts are available on Gentoo in the media-fonts/dejavu package.

The “right” way to change the font globally would be to change the “Sans” and “Serif” and “Monospace” aliases in the fontconfig setup in /etc/fonts. But I generally try to leave those files alone, so instead ran gnome-appearance-properties and from the Font tab changed the system fonts to be what I wanted.

Appearance Preferences

Immediately it fixed my glitch with the weather applet (yeay), but I started to notice anything using the higher order mathematical symbols was likewise drastically improved. Hurrah!

With gnome-font-viewer,

DejaVu Sans Mono, Book DejaVu Serif, Italic

Making screenshots of what they look like on my screen is a bit silly because they won’t necessarily look the same on your screen. But hey. We do our best.

Open Source is about choice, and so I cannot talk about fonts without also mentioning the Liberation font family. These were obtained by Red Hat and intended as a drop-in replacement for the Microsoft core fonts (Courier New, Arial, etc) which are widely used but not libre. For whatever reason the Liberation fonts don’t look quite right on my screen (there are red and green hinting glitches around the glyphs; something is obviously misconfigured somewhere) but it’s a different free font that has been generously made available to the community. They’re available on Gentoo in the media-fonts/liberation-fonts-ttf package.

AfC

Update:

So it turns out that DejaVu is set to be the default on Gentoo, but they’ve got a bug whereby they’ve got their ordering wrong: if you also have Bitstream Vera installed it gets picked up for Sans in preference. The folks in #gentoo-desktop say they’re going to fix that. (This is only relevant if you have the x11-base/xorg-x11 meta package installed; it pulls in media-fonts/ttf-bitstream-vera. If you only have the lower level x11-base/xorg-server package installed you can manually install media-fonts/dejavu [only] and then the default aliases will be to DejaVu). Anyway, the real point of this article was about being aware that you can have control of your fonts, so all good.

Mon, 18 Aug 2008

java-gnome 4.0.8 released!

This blog post is an extract of the release note from the NEWS file which you can read online … or in the sources, of course!

java-gnome 4.0.8 (15 Aug 2008)

Cleanups and fixups.

This release is mostly to push out bug fixes and internal improvements, setting the stage for some major new feature development. We’ve also taken the opportunity to introduce a major change to the way we connect handlers for signals.

New coverage and continuing improvement

With thanks to new contributors Stefan Prelle and Andreas Kuehntopf we have a number of small improvements to the TreeView/TreeModel APIs. As always, Widget and Window saw a bunch of work, with Window.ConfigureEvent now being available and a number of additional property setters and methods relating to window type. Widgets that scroll around a view of a broader underlying canvas have seen a fair bit of activity related to controlling that scrolling.

New features include refinements and new coverage of methods in a variety of lower level classes including that further support drawing operations. Bug fixes, debugging improvements, and defencive enhancements to our thread safety measures have also featured largely.

Signal naming change

The names of the inner interfaces used to specify the prototypes of the methods which receive signal callbacks have changed to the pattern Button.Clicked, this being more appropriate to Java type naming conventions and providing better consistency between the signal name, the method to be implemented to receive the callback, and the method that can be used to emit this signal.

API compatibility to previous releases in the 4.0 series has been preserved. The old signal interfaces and connect() methods are @deprecated. Developers are encouraged to migrate quickly; new coverage will of course all follow the new pattern. Making the transition is is easy, especially in an IDE. Most of the people we’re aware of using the library have already ported their code. Just turn assertions on to double check.

Build changes

java-gnome now defines C compiler flags like GTK_DISABLE_DEPRECATED to ensure we are not linking against code that will be unavailable in GTK 3.0. Many thanks are due to new contributor Kenneth Prugh for having done some terrific grunt work to prune deprecated classes and methods from our .defs data so that java-gnome compiles without using these APIs.

The build system internally now ensures that multiple runs don’t occur simultaneously, fixing a number of annoyances that cropped up when using IDEs which tend to like trying to frequently re-run the build even if a previous one hasn’t finished.

Documentation, examples, and testing

Our API documentation and the growing set of example code have all been updated to reflect the new signal interface names. Doing so forced us to review a wide swath of the documentation, and so along the way a huge number of minor improvements were made. Given how detailed our JavaDoc is, this sort of painstaking work really makes a genuine contribution to overall quality.

There has been steady growth in our test suite, which is great. When combined with the snapshots used to illustrate our documentation, the coverage level is substantial.

Error handling continues to improve. In the (hand written) public API wrapper layer we do our best to catch misuses of the library before they get sent to the native code. But that’s not always possible, and in 4.0.7 we introduced a mechanism whereby GLib error messages get translated into Java Exceptions and thrown. As of 4.0.8, in addition to ERROR and CRITICAL, we also throw WARNINGs as Exceptions. Getting a stack trace this way has proved very useful in helping developers track down where they are making mistakes in using the library.

Conclusion

You can see the full changes accompanying a release by grabbing a copy of the sources and running:

$ bzr diff -r tag:v4.0.7..tag:v4.0.8

Because of the API changes to signal handling this release touches just about every public class in the library and so isn’t quite as clean (as a summary) as in previous releases — but it does show you everything that changed. :)

Looking ahead

Most of the contributors to java-gnome are working on branches that didn’t reach sufficient maturity to be merged in time for 4.0.8; that’s the way it goes sometimes. Major effort continues on implementing coverage of GTK’s powerful TextView/TextBuffer APIs, along with further drawing capabilities in Cairo and Pango. There have also been a surprising level of interest on other areas of the GNOME stack, with new contributors working on adding support to java-gnome for Nautilus, GStreamer, and even WebKit. Exciting stuff!

You can download java-gnome from ftp.gnome.org or easily checkout a branch from ‘mainline’ using Bazaar:

$ bzr checkout bzr://research.operationaldynamics.com/bzr/java-gnome/mainline java-gnome

AfC

Things to do after you’ve won gold at the Olympics

Australians Nathan Wilmot and Malcolm Page won the gold medal sailing in the 470 class yesterday. Wilmot announced that he would be retiring (from racing that class, anyway).

When asked his immediate plans, the Sydney sailor replied “getting fat”

— as quoted by Alex Brown in “One pair just had to turn up, the other had to finish breakfast”, The Sydney Morning Herald, Tue, 19 Aug 08, Olympics section, page 1.

Maybe he should try the Michael Phelps diet.

AfC

Thu, 07 Aug 2008

What to do when dodging a hail of bullets

After watching my copy of the Bourne Ultimatum the other day, I started wondering how a newspaper like The Guardian feels about being portrayed in such a film. Via one of the footnotes in the Wikipedia entry, I found my way to an article on their website on this very topic:

Obviously, I would have preferred to see this Guardian journalist do a little more ass-kicking, or indeed any ass-kicking … Nevertheless, he gets to show a fair bit of courage under fire. He and Bourne are shadowed by a creepy CIA surveillance spook who has already given a chilling order to “prepare rendition protocols”. Huh! Bring it on! Guardian journalists aren’t scared of Guantánamo.

The best part was the insight into the newspaper’s style guide:

They wind up in Waterloo station where they have to dodge bullets from a CIA sniper, that of course is the sort of thing which happens to us all the time. But there are inaccuracies. The Guardian stylebook clearly states that if you are under a hail of bullets in a public place from an assassin run by a deniable intelligence unit, you have to duck into the nearest internet cafe and start blogging about it to keep the readers informed.

The BBC’s website, by contrast, advises readers not to risk themselves when submitting comments from dangerous places like the scene of a protest being violently suppressed by the faceless state police, or when an earthquake is destroying the building they are in, or when walking down the streets of London. How can we possibly defend democracy in the face of such reticence?

:)

AfC

Comments have been disabled so that readers do not endanger themselves replying to this blog post.

Fri, 01 Aug 2008

Swat!

Huge kudos are due to Cody Russell for having fixed one of the longest-standing bugs in GTK. 11 June 2001!

Cody only got involved in this issue recently, but he took the time to really dig into it, examine different hypothesises, and test like crazy. This was remarkable: it’s not every day you see someone wade into a bug that’s been open for over half a decade and with over a hundred comments, and then persist for over a year to get it solved.

Way to go!

AfC

Fri, 11 Jul 2008

The Great Storm of 1703

Looking into disaster scenarios and doing actuarial and engineering forecasts of potential impacts, I came across a fascinating paper about the impact of “The Great Storm of 1703“¹ on southern England and the Channel coast. Obviously this predates modern meteorology, so what makes it interesting is how they modeled what the wind forces likely were.

Given that there is every likelihood that such conditions can arise again, the forecast of the economic impact (specifically, claims in excess of available reinsurance) means such and event would likely have a catastrophic effect on the financial system if it had already been weakened by other difficulties — kind of like as it is at present.

AfC

¹ A 7 page retrospective published in .pdf form by a firm named Risk Management Solutions at their website. The fate of the Eddystone Lighthouse, pictured above, is also interesting.

Sun, 06 Jul 2008

Using Eclipse’s source code formatter from the command line

One of the many wonderful capabilities built into the side of Eclipse is a powerful code formatter. Adjusting source code to match one’s particular preferences is nothing terribly new; what makes Eclipse’s so excellent is the degree of configurability and the preview of the effect each setting will have.

An Eclipse project has several metadata files:

.project
.classpath
.settings/org.eclipse.cdt.core.prefs
.settings/org.eclipse.jdt.core.prefs
.settings/org.eclipse.jdt.ui.prefs

Which seems a bit of a mess, but whatever. The .settings/ stuff gets written down when you decide to tell a Project to have settings custom that override the user’s defaults. It goes without saying that for a collaboratively developed project like the Java bindings we have the Eclipse project metadata for compiler warnings tuned, the code formatter settings, how to invoke the build system etc all stored in Bazaar along side the real sources.

Anyway, this’s all fine and nice for people working on my software in Eclipse, but what about people wishing to use a different editor?

For a few versions now, Eclipse has exposed the the ability to run its code formatter from the command line; the work was done by Ben Konrath, someone I met a few years ago at a java-gnome hackfest. Since I use Eclipse I hadn’t needed to bother to figure out how to use whatever it was that he’d done. Since becoming maintainer of java-gnome, though, I’ve noticed a bit of unnecessary formatting churn in the contributions we receive. We do have a style guide, but it is secondary to the fact that Eclipse just normalizes the code every time I save something (nice). But for people not using Eclipse I thought I might have a look.

A bit of searching around turned up this blog post by one Peter Friese. It included two important points that are non-trivial. Firstly, that configuration the code formatter from command line will use can be controlled by the pointing it at the .settings/org.eclipse.jdt.ui.prefs file which in turn can be created by the “Enable project specific settings” described above (we’d already done that, so no problem, but how on earth would anyone have guessed this?). Secondly, the command line that one has to incant to make it go is pretty voodoo, so I’m pretty thankful that he described what he’d done.

In our environment, this works out to:

$ /opt/local/eclipse/eclipse -nosplash
    -application org.eclipse.jdt.core.JavaCodeFormatter
    -verbose
    -config .settings/org.eclipse.jdt.core.prefs
    src/ tests/ doc/examples/

Gah!

For a brief moment I wondered if it would be easier just to run the Java class in question. So I interrupted the process and had a look in the process table.

/usr/lib/jvm/sun-jdk-1.6/bin/java
    -Dosgi.requiredJavaVersion=1.5
    -client
    -Xms40m
    -Xmx256m
    -jar /opt/local/eclipse/plugins org.eclipse.equinox.launcher_1.0.1.R33x_v20070828.jar
    -os linux
    -ws gtk
    -arch x86
    -launcher /opt/local/eclipse/eclipse
    -name Eclipse
    --launcher.library /opt/local/eclipse/plugins/org.eclipse.equinox.launcher.gtk.linux.x86_1.0.2.R331_v20071019/eclipse_1021.so
    -startup /opt/local/eclipse/plugins/org.eclipse.equinox.launcher_1.0.1.R33x_v20070828.jar
    -exitdata 84001b
    -application org.eclipse.jdt.core.JavaCodeFormatter
    -verbose
    -config .settings/org.eclipse.jdt.core.prefs
    src/ tests/ doc/examples/
    -vm /usr/bin/java
    -vmargs
    -Dosgi.requiredJavaVersion=1.5
    -client
    -Xms40m
    -Xmx256m
    -jar /opt/local/eclipse/plugins/org.eclipse.equinox.launcher_1.0.1.R33x_v20070828.jar

Good Lord. What the hell is all that? I mean, I know Java environments tend to get a bit unwieldy because there is still no link-to-binary facility, and I know Eclipse is an OSGi framework and what not, but that is pathetic. I guess running the command as described at the top isn’t such a bad idea after all.

I’ve got an even better idea: how about a convenience target in our Makefile front end. Yup. So I’ve added a format target:

$ make format

(or

$ ECLIPSE=/opt/local/eclipse/eclipse make format

in my case). Running that before committing will do the trick quite nicely.

I agree with the bug mentioned by one Nicholas Irving in his post on the topic: it is somewhat asinine that this bit of Eclipse bumps the modification time of every file it formats; it would be nice if it only changed files in which it actually found something it needed to alter. Fortunately our internal build system is actually md5 hash (not Make) based, so it doesn’t hurt us.

AfC

Mon, 30 Jun 2008

Low flying aircraft

Late this morning people in Sydney were treated to the sound and then sight of a largish four engine aircraft flying a somewhat unusual and fairly low flightpath on its way across the Northern Beaches on approach into Sydney. What made it a bit more interesting was:

the thing was painted gray
it had a fighter flying in close formation off its tail

Huh. Certainly a bit unusual to see on its way into SYD, but the fact that it was obviously a military aircraft, with a fighter escort, was more than reassuring. Mostly we figured it was a head of state or senior officer from some allied nation on the way in, getting a nice escort. I will admit that Katrina and I are both a little jumpy when it comes to very loud engines close overhead; the scream from the fighter’s jet engine mixed in did give it an unusual timbre. (Which most people aren’t used to; if you haven’t experienced fighters up close and personal, it’s not a roar but more a thin penetrating shriek. Hollywood never gets these things even remotely close). So, {shrug}. Residual jumpiness aside, what I learned from the last time a large jet flew down my street is that if you are hearing the engines firewalled, at least it is already past you.

Anyway, it all turns out to be quite innocent. The Royal Australian Air Force is retiring it’s last Boeing 707, and they did a photo shoot over Sydney. How nice.

Even though I only got a brief glance, I should have recognized the airframe. Bah. The US military still fly a number of C135 derivatives; that it might have been one did flash through my mind, but I they’re kinda getting on in years and I didn’t expect to see one hereabouts. A 707 isn’t that large, but sometimes scale is hard to tell from afar. Alas

I wouldn’t have ever given it a moment’s thought again except that a glance this evening at a local paper’s website showed it headlining an article about it, much to my surprise. Somewhat less of a surprise was them using the occasion to be all alarmist about low flying planes over cities.

After we get past the quotes of office workers who were terrified and who ran screaming from their buildings, we get to the mention that the plane was “trailing smoke”. That’s awesome. Uh, in case you didn’t know, that’s what turbofan engines do at low speed. Airplanes are made to be efficient at high altitude cruise. Pouring out power to keep a plane going at low speed is, unfortunately, somewhat inefficient. Kinda like your car starting after a red light. Jet engine manufacturers work hard on this sort of thing, but older planes are (surprise) less efficient. Which is why aircraft manufactured in the 1960s are somewhat less than ideal from an operations cost standpoint. Not to mention noise, and, yes, the black gunk pouring out the back.

The principal complaint is that people seem to feel they should have been told about this. While I’m sure the press will be full of scary headlines in the morning, and no doubt the politicians will hang the Air Force out to dry, the air navigation regulations for the Sydney terminal airspace clearly allow for aircraft doing photo op orbits over Sydney harbour and explicitly detail the procedures to be used. Gotta get that bridge and concert hall in or it just doesn’t count, right? So, quite sensibly, ATC around Sydney allows for pilots requesting permission to do so.

Now, admittedly, the average photo op by a circling Cessna doesn’t attract much attention; a largish jet is a bit more ostentatious. Neglecting for a moment that most of the approach paths bring low flying aircraft right over Sydney and its suburbs anyway, should the populace be given advanced notice of plans to orbit planes a bit lower? Hm.

Apparently at least one local radio station did know about this ahead of time, so I’d say the RAAF did its part¹ (and that’s assuming that it had an obligation to do so, which frankly, I’m not convinced of). If the journos didn’t think it newsworthy to mention in their broadcasts, that’s not the Air Force’s fault. And there in lies the problem. So long as the media is busy reporting on the latest antics of Britney Spears and how the 6 year long US presidential election campaign is getting on, I doubt there will ever be much time for public service announcements, even if we did decide that such things were topical.

AfC

¹ Update: Here’s the Department of Defence press release, released last week.

Wed, 11 Jun 2008

Voyager and the speed limit

As often happens, an IRC channel veered off-topic and onto an interesting one instead. We got to talking about clocks and frames of reference and while we were chatting back and forth someone claimed that we hadn’t made anything that had reached relativistic speed yet (or, at least nothing on the scale of the questions you get on your average physics exam about the spacecraft doing 0.9c). That may be true, but that had me wondering just how fast the fastest thing was.

That would be Voyager 1, launched 5 September 1977. It’s now about 15.9 billion km out, and is booking along at about 17 km/s which is 0.000056c. That’s pretty fast! Still going to take a while to get to the next stop, though.

Image Credit: NASA/Walt Feimer.

Finding the speed number led me to a JPL page on the NASA site about the Voyager missions. Quite interesting reading, especially about the choice of trajectories they had which allowed them to have Voyager 2 reach not just Jupiter and Saturn but also Uranus and Neptune in “12 years rather than 30”.

http://voyager.jpl.nasa.gov/news/factsheet.html

AfC

Thu, 15 May 2008

A Bazaar branch of GTK

Converting a project from one version control system to another is always painful. Doing so is a rather momentous change to contemplate. With organizational & community inertia being what it is, not something easily rushed into. Worse is when you attempt to use a modern tool as a better front end for an old one.

One of the neat things about the 3rd generation distributed version control system projects (ie Bazaar, Git, or Mercurial) is their plugins which allow you to continue to work with a Subversion upstream project but use the modern tool as a front end locally. For those of us who have been very productively using DVCS for some time, this is a godsend.

Using one of these plugins to thence evaluate the usability or performance of one of a DVCS is not really the best approach one could take; none of them were built with using Subversion as a peer in mind, and lord knows Subversion is not built to store revisions with such complex relationships. Thus the idea has turned out to be a very challenging problem space for everyone but most have had their tools mature to the point where Subversion is the bottleneck. And despite my misgiving that starting out your experience with a 3rd generation DVCS by first using it to access some legacy project will not show your new shiny tool in its best light, the reality remains that most people need to get on with being productive, and doing a full blown conversion (or starting use with a brand new projects) are less likely to be your circumstance.

Having been using Bazaar (known best by the abbreviation bzr) for well over 18 months and overall being very happy with the experience, I would like to encourage other GNOME hackers to try it; likewise I have some patches I’d like to contribute to GTK so I thought I’d start by using bzr-svn to get a branch of GTK as a starting point (and to likewise give Bazaar’s Subversion interface a workout). So I created Bazaar branch of GTK.

Initial import was very slow

The first step was to create a Bazaar branch that represents the foreign Subversion repository. This was painful.

I originally attempted to do this while I was at the GTK Hackfest we had in Berlin; that turned out to be a disaster because (as one does at a conference or meeting) we were moving around every few hours connecting and disconnecting from the ‘net, and I was busy trying to do this from my laptop rather than a server somewhere. (Unfortunately bzr-svn relies on a memory fix that is not yet in the released version of Subversion, and not every distro has their Subversion patched with it). So that fell flat on its face.

I was able to restart the process a week or two later and leave it running overnight. Along the way I’d learned a technique for doing a few hundred revisions at a time (do bzr pull -r $i in a loop and increment the variable by a hundred or whatever each cycle) and so was able to cope with the need to disconnect periodically. Which is well, because it took 2 days to do the import.

While I was at first appalled by this, I really can’t blame Bazaar. The GTK codebase is, of course, rather large. First preserved commits were in 1997; there are over 15,000 revisions; a working tree (excluding VCS metadata) is 83 MB in size. The bigger problem however, is that Subversion is not fast at accessing historical data (the time taken to process revisions started at over 32 minutes per 100 but eventually dropped to about 9 minutes per 100 as it got to the most recent history; interesting).

Clearly, I could have picked an easier example for my experiments with bzr-svn, but it’s done now.

Usage is fine once branch created

I wasn’t entirely sure whether the DVCS property that branches are all peers would apply to one that had started life backed by a Subversion repository would hold, but things work just as they are supposed to. Creating a new branch to work on a feature with bzr branch, or use the technique of using a bzr checkout along with bzr switch to do change-in-place, both worked fine. So I’m all set.

The real point, though, was to encourage more GNOME hackers to give Bazaar a try. If everyone had to put up with a endless import process like mentioned above then no one would touch it. But now that the branch is created (and up to date as of yesterday or so), anyone can use it.

With Olav’s concurrence, I put my branch on in my GNOME directory, so you can branch from it as follows:

$ bzr init-repo --rich-root-pack gtk+
$ cd gtk+/
$ bzr branch http://www.gnome.org/~afcowie/bzr/gtk+/trunk/

You do the first step so that you can create a “shared repository” (in Bazaar parlance) which will allow that various branches under that directory will share all the revision data for the project. I need to warn you, though. Modern DVCS tools give you the full history of the project, but for a large project that can be pretty big. If you grab the above branch you’ll be downloading about 180 MB and it takes about 5 minutes. Yes 5 minutes is a long time, but no there’s no way around it* and in any case 180 MB is not unreasonable for such a mature project. Don’t be too worried if it seems like it is taking a bit to do the transfer. You only need to do it once, and look on the bright side. It took me 2 days. Just let it run.

Workin’

Personally, I always do my work in a working branch separate from my mirror of upstream, allowing me to easily compare against the last update of upstream that I have done. So:

$ bzr branch trunk working
$ cd working/
$ ./autogen.sh
$ make

and away we go. Branching takes like 3 seconds. Nice and fast, no problem.

I haven’t got a script running religiously updating my GTK branch; I do a bzr pull locally once every few days in my copy of 'trunk' and have been pushing that up to http://www.gnome.org/~afcowie/gtk+/trunk/. But now that you’ve got the branch, you don’t have to rely on me anymore; this whole distributed thing kicks in and you can do it yourself. Assuming you have a svn.gnome.org account, then you can update with:

$ cd ../trunk/
$ bzr pull --remember svn+ssh://username@svn.gnome.org/svn/gtk+/trunk

(use the --remember argument the first time to change where it updates from by default so you’re not relying on my branch anymore) and push with:

$ bzr push svn+ssh://username@svn.gnome.org/svn/gtk+/trunk

The very first time you update from Subversion bzr-svn will have to build some caches and whatnot locally, but it’ll be pretty fast from there on.

I’m ignoring the pushing and pulling of revisions between your mirror of ‘trunk’ and your local 'working' (or whatever) branch; I’m sure you can figure that part out yourself: but here’s a hint: do your work, test it, and commit it, all in 'working'; repeat; then use, say:

$ bzr diff -r ancestor:../trunk/

to consider what your current patch looks like, then shuttle it to 'trunk' with bzr pull or bzr merge (assuming you run it from 'trunk’ and whether you need to merge or not) and then bzr push to svn.gnome.org. Hope it works for you.

If you need help, poke your head into #bzr on FreeNode or write to their mailing list, or ping me and I’ll try and lend a hand. Make sure you’re using the latest releases; I doubt it will work otherwise and so recommend that you use bzr >= 1.4.0 and bzr-svn >= 0.4.10. Older versions do not contain critical bug fixes. I also encourage you to grab bzr-gtk >= 0.93.0 as the visualize command it adds:

$ bzr viz

is really amazing.

Good luck!

AfC

Update:
You need to have PycURL installed (it’s an optional dependency; used at runtime if detected). There is a bug that will prevent you doing the branch from me if you don’t. Debian and Ubuntu package python-pycurl; Gentoo USE=curl pulls in package dev-python/pycurl; Fedora package is also python-pycurl.

* Interestingly, the Bazaar hackers are working their way towards a “shallow branch” capability, which will be really cool; really, we don’t need 15,000 revisions of history just to tweak some project; we need the last 100 or so so we can branch from it, build, fix something, commit, and then submit the resultant revision upstream. Full history is wonderful and frequently useful, but this will be hand to help reduce the data transfer barrier to casual contribution in cases where bandwidth is at a premium.

This very moment as the GNOME systems administration team is presently working through the consequences of the Debian SSH key vulnerability; they have for the moment very properly locked down all access to the services provided to GNOME hackers, and that knocks out access to the Subversion server meaning people can’t work with their source code properly. If there was ever a clearer demonstration on the inadequacy of old 1st generation centralized version control systems, I cannot think of it.

Mon, 05 May 2008

java-gnome 4.0.7 released!

This blog post is an extract of the release note from the NEWS file which you can read online … or in the sources, of course!

java-gnome 4.0.7 (30 Apr 2008)

Draw some.

In addition to the usual improvements to our coverage of the GNOME libraries, this release introduces preliminary coverage of the Cairo Graphics drawing library, along with the infrastructure to make it work within a GTK program.

Drawing with Cairo

Example

The trusty Cairo context, traditionally declared as a variable named cr in code, is mapped as class Context. Various Cairo types such as different surfaces and patterns are mapped as an abstract base class (Surface, Pattern) along with various concrete subclasses (ImageSurface, XlibSurface, and SolidPattern, RadialPattern, etc). Error checking is implicit: the library status is checked internally after each operation and an Exception thrown if there is a failure.

Thanks in particular to Carl Worth for having reviewed our API and having helped test our implementation.

New coverage and continuing improvement

The single option choice buttons in GTK are called RadioButtons and have now been exposed. When using them you need to indicate the other buttons they are sharing a mutually exclusive relationship with, and this is expressed by adding them to a RadioButtonGroup.

RadioButton

The usual steady refinements to our coverage of the GtkTreeView API continue. There’s a new DataColumn type for Stock icons, and TreeModelSort is now implemented, along with minor changes to various other miscellaneous classes.

Considerable internal optimizations have been done, especially relating to ensuring proper memory management, with notable refinements to make use of “caller owns return” information available in the .defs data. This fixes a number of bugs. Thanks to Vreixo Formoso for having driven these improvements.

Error handling has been improved for GLib based libraries as well. If an ERROR or CRITICAL is emitted, our internals will trap this and throw an exception instead, allowing the developer to see a Java stack trace leading them to the point in their code where they caused the problem.

Internationalization support

java-gnome now has full support for the GNOME translation and localization infrastructure, including the standard _("Hello") idiom for marking strings for extraction and translation, but combined with some of the powerful support for positional parameters available from Java’s MessageFormat as well. There’s a fairly detailed explanation in the Internationalization utility class.

Build changes

Note that as was advertised as forthcoming some time ago, Java 1.5 is now the minimum language level required of your tool chain and Java virtual machine in order to build and use the java-gnome library.

Thanks to Colin Walters, Manu Mahajan, Thomas Girard, Rob Taylor, and Serkan Kaba for contributing improvements allowing the library to build in more environments and for their work on packages for their distributions.

The download page has updated instructions for getting either binary packages or checking out the source code.

Documentation, examples, and testing

Refinements to the API documentation continue across the board, notably improving consistency. A large number of javadoc warnings have also been cleaned up.

While not a full blown tutorial, the number of fully explained examples is growing. There are examples for box packing and signal connection, presenting tabular data, and basic drawing, among others. See the description page in the doc/examples/ section.

This code, together with the not inconsiderable number of unit tests and the code for generating snapshots of Widgets and Windows means that a large portion of the public API is tested within the library itself. The number of non-trivial applications making use of java-gnome is starting to grow, which are likewise providing for ongoing validation of the codebase.

Summary

You can see the full changes accompanying a release by grabbing a copy of the sources and running:

$ bzr diff -r tag:v4.0.6..tag:v4.0.7

Looking ahead

It’s probably unwise to predict what will be in future releases. The challenge for anyone contributing is that they need to understand what something does, when to use it (and more to the point, when not to!), and be able to explain it to others. This needs neither prior experience developing with GNOME or guru level Java knowledge, but a certain willingness to dig into details is necessary.

That said, I imagine we’ll likely see further Cairo improvements as people start to use it in anger. It shouldn’t take too long until the bulk of the functionality needed for most uses is present in java-gnome. In particular, forthcoming coverage of the Pango text drawing library will round things out nicely.

There are a number of other major feature improvements we’d like to see in java-gnome. Conceptual and design work is ongoing on for bindings of GConf, GStreamer, and even support for applets. Within GTK, there have been a number of requests made for various things to be exposed, for example, the powerful GtkTextView / GtkTextBuffer text display and editing capability. Some of these have preliminary implementations; whether or not any given piece of work is acceptable in time for any particular future release will remain to be seen and depends on the willingness of clients to fund us to review and test such work.

In the mean time, people are happily using the library to develop rich user interfaces, which is, of course, the whole point. We’re always pleased to welcome new faces to the community around the project. If you want to learn more, stop by #java-gnome and say hello!

You can download java-gnome from ftp.gnome.org or easily checkout a branch from ‘mainline’ using Bazaar:

$ bzr clone bzr://research.operationaldynamics.com/bzr/java-gnome/mainline java-gnome

AfC

Wed, 30 Apr 2008

No crisis for me

I was chatting with Atul earlier today when he expressed his dismay that Slashdot was off the air and asked me if I could get there? No. Meanwhile, I realized I couldn’t get to SourceForge. This was proving problematic as I had just done a release of an Open Source project I’m the maintainer of, and was trying to update the project website. Guess announcing the release will have to wait a bit :(.

Oh well. “The internet must be broken somewhere”.

We then recalled that these are both services of OSDN. I recall a few years back talking with the system administrators there about crisis management in IT environments and using procedures to manage change. They said they didn’t need any help with their operations. “We’re all set”. Uh huh. People always say that when things aren’t going wrong.

—

Of course, it is now 3am in California. It actually doesn’t matter where your servers are — it’s always 3am when things like this go wrong. Personally, I take it as conclusive proof about the underlying nature of the universe that this sort of thing only happens when it is the middle of the night. You can’t possibly find a less pleasant time to force sysadmins to get out of bed and to go try and fix things. Frankly, I think that’s just Someone trying to tell sysadmins that they made a poor career choice, but you know, He (or She, or It, or They, take your pick) needs to have a good laugh too.

AfC

Thu, 10 Apr 2008

Sun’s secret web server

For a while now I’d been looking for something to just run up an HTTP server to answer simple queries.

The Java Servlet APIs are comprehensive, and there are a number of very good implementations (we use Resin in highly loaded environments and it scales like a dream; we recommend it heartily to our clients). Nevertheless, sometimes you’re working on something small or ad-hoc, and you just want a simple web server that doesn’t involve application descriptors, XML, configuring an entire service instance, and everything else. Somewhat to everyone’s long standing annoyance (not to mention the derision of people who work in other languages), there is nothing in the Java standard library to just get on with this.

In their release of Java 1.6, however, Sun quietly included such a server. Apparently it had been around for some time powering internals of various other projects, but in 1.6 they exposed it as a public library, in package com.sun.net.httpserver, and it ships alongside the rest of their Java VM and standard library.

It’s got a rather nice API. You fire up a server and add one or more handlers:

        addr  = new InetSocketAddress("localhost", 8000);
        server = HttpServer.create(addr, 10);
        server.createContext("/eg", new ExampleHandler());
        server.start();

the “contexts” are paths from root that are handled by different HttpHandler instances; implementing that interface is simply:

    public void handle(HttpExchange t) throws IOException {
        ...
    }

Once there, you’ve got a number of really straight forward methods on HttpHandler to get done what needs doing:

        t.getProtocol();
        t.getRequestMethod();
        t.getRequestURI();
        t.getRequestHeaders();
        t.sendResponseHeaders(code, length);

for the metadata, and an InputStream and an OutputStream from:

        t.getRequestBody();            
        t.getResponseBody();

respectively. You write the response to the later. Too easy. I did up a modified version of the example they have in the package description file as something that echos back the HTTP request as the response and it was quite straight forward. Java programmers can glance at EchoServer.java if they’re interested.

The catch

Nothing is ever simple. The bytecode for the com.sun.net.httpserver package is bundled in with the rt.jar that comprises the bulk of the standard library, but for whatever reason they didn’t include the JavaDoc for these classes in the same tree as the rest of the API documentation.¹ This is a huge pain, because once you’ve told Eclipse where to look for the docs for a given blob (in this case, for rt.jar) you can’t then tell it to look somewhere else for a sub part. And if you’re trying to develop something in a beautiful IDE like Eclipse, the idea of not having inline popup documentation and completion working properly is just a non-starter.

You can point Eclipse at either a JavaDoc tree, or at the raw sources and it’ll just extract the documentation on the fly. But since the src.zip shipping with Sun’s proprietary Java 1.6 didn’t include the classes for this web server code, that didn’t work either.

So that would have been the writing on the wall for Sun’s httpserver.

Open Java to the rescue

After chatting with some people in #gentoo-java and #classpath, we suddenly realized that the solution was at hand. Source code to Open Java is available.² And even though it’s still not yet a fully Libre replacement for Sun’s proprietary Java 1.6 (the size of the binary proprietary plugs you have to drop into it to make it work is staggering), it does contain most of the sources to the Java standard library. So we grabbed a copy of the openjdk 1.6 b08 code drop, and just pointed Eclipse at it as the sources for rt.jar for cases where it couldn’t find the JavaDoc when it was looking something up. And ta-da!

So, amidst considerable astonishment but great pleasure, here was an example of something someone had Open Sourced working in a synergistic way but in a way that they hadn’t quite expected. This wouldn’t have worked if Sun hadn’t Open Sourced (most of) Java; but because they have we were able to use those sources to solve a problem. Thanks to the heroes at Sun Microsystems who made this possible!

Eclipse users will have to adjust their filters so that com.sun.* isn’t excluded from Type completions and what not; While we’ve all loved our com.sun.* excludes, it blots out com.sun.net.httpserver. If you plan on using it, then I suggest switching to excluding com.sun.org.* and com.sun.xml.*, etc. A pain, but that’s what we get for Sun not having put this into the standard library.

Speaking of which, I doubt we’ll ever see this as a part of the “Java” (wouldn’t java.net.httpserver just do the trick?) because the marketing side of Sun has a fairly strong fixation on “Servlets are what you use for everything”. Oh well. It would be a really pleasant surprise, though. Here’s hoping.

But not really

We would never use this in something we were distributing to anyone outside; after all, they might be using some other VM and com.sun.net.httpserver isn’t available as a standalone library. And that’s not to mention scalability; if you need something bulletproof then use the Resin servlet runner. But if you need a quick-and-dirty but easy-to-use HTTP server and you happen to have Sun Java or the future tense Open Java available, then this should do the trick for you. And if you’re feeling like whipping up something of your own, this really does have a nice API (somewhat a rarity in the Java landscape) and so this might be a good starting point for you. Either way, have a look.

AfC

¹ As mentioned, the API docs for com.net.sun.httpserver are not in the usual location at docs/api/ along with the rest of the standard library but at docs/jre/api/net/httpserver/spec/ of all places. Who knows what they were smoking that day.

² I am very tired of apologizing to people who have just installed “Java” on their Linux boxes that they have to download something else. I’ve given up trying to explain the difference between a JRE and a JDK to people; even after I do people respond with “who cares; I just want a working Java that I can use to build your software.” Sun having attempted to brand their Libre implementation of Java as “Open JDK” just perpetuates this nonsense. Not including the compiler classes in something that is already 18 MB big is stupid, and it’s not like the desktop VM is what you use on a resource limited embedded device. Open Java works just fine as a name, thank you very much, and it is (almost) a Free Java. Almost.

Sat, 05 Apr 2008

Cairo drawing from java-gnome

We’ve added support for the amazing Cairo Graphics library to the Java bindings for GTK and GNOME.

Adding Cairo is a feature we’ve been working on for about 6 months now, and so I’m pretty pleased that during the 4.0.7 development cycle we’ve been able to land it. Cairo is a huge library, of course, but we’ve put enough coverage in place to ensure that things are working.

Cairo has lots of convenience functions and tons of obscure uses; no surprise (and no apology) that there’s still lots that will need doing. If you want to help make sure it has what you need, then grab ‘mainline’ and see org.freedesktop.cairo.Context and ExampleCairoDrawingInExposeEvent.

Huge thanks go out to Behdad Esfahbod and Carl Worth; Behdad was really critical in explaining some basic Cairo concepts to get me started when we were working together at the GNOME Summit back in October in Boston, and at the GTK hackfest in Berlin in March, Carl Worth checked our preliminary APIs and helped sort me out as we were working our way through to create some examples. Awesome!

example

java-gnome 4.0.7 should be out in the next week or two, depending on how long it takes to finish up testing, QA, and to do the release engineering.

AfC

Fri, 04 Apr 2008

Upgraded!


#gnome-hackers		#gentoo-desktop

The upgrade to GNOME 2.22 went really smoothly. Well done to the Gentoo Linux desktop team for their heroic efforts bumping so many .ebuilds, and congratulations to all the GNOME hackers, testers and translators around the world on what continues to be superb software!

AfC

Tue, 04 Mar 2008

Passing through

I’m in London for a few days; I have a few meetings set up for while I’m here, but we’re always on the lookout for people with new and interesting problems. If anyone reading this is battling to get their IT operations into shape, or perhaps has a major enterprise system critical to their business that is not living up to expectations, then by all means get in touch. We also have long experience with clients who run large Java systems on Linux, and problem solving in those environments continues to be the focus of much of our work.

If you’re facing issues in any of these areas and need to do something about them, I’d be more than pleased to meet with you while I’m here. You can leave a message for me on 0207 101 9201 or call my mobile +61 4 1079 6725; my email address is andrew@operationaldynamics.com.

Given the Java on Linux preoccupation, it’s no surprise that a few years ago I became the maintainer Java bindings for the GNOME Desktop (a project which allows people to use GTK and the other GNOME libraries from to create powerful Linux applications while leveraging their existing expertise with Java). That’s the reason I’m on the road this particular trip; the GNOME Foundation has organized a GTK hackfest in Berlin next week and I was kindly invited.

I’ll be in Toronto the week after, so again, if someone would like to meet, please don’t hesitate to call; 647 477 5603.

Actually, this whole blog post is a bit of a misnomer. It doesn’t matter where you are located, nor where I or any of my staff happen to be any given week. If you have systems that are critical to your business, need to prevent crisis from occurring, trying to manage change better, or looking to review your architecture so you can optimize your use of technology and ensure scalability, then don’t hesitate to contact us, anytime.

AfC

`--` Andrew Frederick Cowie Managing Director

Sydney	New York	Toronto	London
`+61 2 9977 6866`	`+1 646 472 5054`	`+1 647 477 5603`	+44 207 101 9201

Mon, 25 Feb 2008

Get Some

The other day I was wading through Ulrich Drepper’s paper about how memory works these days and what programmers should do as a result.

My wife asked me what I was reading. I showed her the title and when she saw it concerned computer memory, she looked at me with a totally straight face and summed up the 114 page paper by answering “Yes, you should get some”.

Like most of Ulrich’s writing, this paper is immense: long on detail and well presented. I must admit that I agreed with many others that after having read the work I was left wondering what action, in practical terms, I should be taking as a result. Clearly most of this knowledge is very important for Kernel hackers and for those doing low level systems programming, but since I do higher level work (ie advising people with large enterprise systems), it is hard to asses the choices I might be making in the terms of what Ulrich describes. I can only hope that the people who work on the parts of the low level libraries that run next to the metal (such as drivers, GLib, and especially the VMs like the Java and Python runtimes) are aware of these issues and making design choices based on these insights.

AfC

Tue, 12 Feb 2008

java-gnome 4.0.6 released!

This blog post is the release note from the NEWS file which you can read online … or in the sources, of course!

java-gnome 4.0.6 (12 Feb 2008)

Finding the missing methods.

Most of our effort recently has simply been fleshing out areas of the public API. The focus for this work as been getting the coverage needed to allow us to port some of our in-house applications to java-gnome 4.0. It’s not especially glamorous — if anything it has been tedious as hell — but the result has been a large body of improvements to java-gnome as a whole which we’re pleased to release as java-gnome 4.0.6

The bulk of this development took place on the ‘missing’ branch, so named because that’s where I was working on what was missing :).

Continuing Improvement

Notable public changes include coverage additions to enable key stroke and mouse button handling

Rather than exposing the int keyvals that bubble up out of the X server, we have wrapped these as constants of type Keyval (thereby being consistent with the rest of java-gnome in our working to the strengths of Java as a strongly-typed language; MouseButton was created for the same reason, helping developers understand just what on earth mouse button “1” is, anyway). Along with ModifierType, this gives enough to deal with the KEY_PRESS_EVENT and KEY_RELEASE_EVENT signals when the developer wishes to deal with key strokes.

We’ve finally gotten around to providing proper coverage of the box packing model which underlies every aspect of how GTK presents user interfaces. To understand the size-request/size-allocation process, you might start with Widget’s setSizeRequest().

We’ve also added coverage for SizeGroup, which, when used in concert with nested VBoxes and HBoxes, can work wonderful magic and is often far better than messing around with Table when doing complex layouts.

After dithering for several releases, we’ve settled on how we’re going to deal with ComboBox and family. The underlying GtkComboBox presents something of a nightmare as it is really two classes in one with more-or-less incompatible APIs. So, not surprisingly, we’ve presented it as two sets of classes, with the text-only convenience API spliced out of ComboBox and ComboBoxEntry into TextComboBox and TextComboBoxEntry respectively.

We’ve added a few new features in our coverage of GTK’s TreeView / TreeModel API, and many other classes involved have also seen improvements. The persistent reference to a row provided by TreeRowReference is now available as is model type TreeModelFilter.

Support for the actual filtering in TreeModelFilter is notable for having been quite tricky. The underlying C library use a function pointers rather than a GObject signal emission, and we don’t have any mechanism to handle that. We do, however, have a fantastic capability to marshal signals, so we dealt with the problem by creating a custom signal and then passing a function which emits it when the TreeModelFilter wants to ask the developer whether to include a row or not.

The new classes include support for TreeModel columns storing long data as well as setting properties of that type.

It should also be noted that most of the methods taking a TreeViewColumn have been converted to taking an argument of type CellLayout (an interface implemented by TreeViewColumn). This has no change to how you use our TreeView API, but was necessary to support ComboBox properly.

Finally lots and lots of minor additions to both public APIs and internals deeper down in the GDK part of the toolkit.

As ever, you can see the full changes accompanying a release by grabbing a copy of the sources and running:

$ bzr diff -r tag:v4.0.5..tag:v4.0.6

Documentation

We’ve always had HTML JavaDoc for the current stable release at doc/api/ on the java-gnome website. We’re going to change that a bit, though. As fixes to the explanatory documentation happen quite frequently to classes and methods all over the place, we’ve decided to generate the JavaDoc from ‘mainline’ periodically and upload that instead. This means that there will, of course, be descriptions of some methods which aren’t yet available in a released version of the library, but they will clearly identifiable by virtue of having a @since tag showing a version number greater than the most recent release. We’ll revert back to more traditional behaviour once we hit 4.2.0, but in the mean time we can give people access to the best information we can online.

The idea of having up-to-date illustrations of the various Widgets has proved popular, and we’ve continued to update the suite of snapshots. Doing that is also tedious, but it does provide a good opportunity to test APIs we are exposing especially where unit tests are less suitable.

Statusbar

Looking ahead

Almost as complex as the TreeView / TreeModel API are GTK’s powerful TextView / TextModel classes, collectively a Widget used to display and edit large text documents. Working out the java-gnome coverage for TextView will take a fair bit of consideration, but TreeView provides a road map, and, as with the coverage in 4.0.5 and 4.0.6 (which was driven largely by existing applications we were porting), we have some significant uses of GtkTextView which will guide us on our way.

The next release will also feature significant work outside of GTK; we should be in a position to merge our coverage of the excellent Cairo drawing library soon, and likewise we have tentative work in place letting people store configuration and settings data in GConf. Both the ‘cairo’ and ‘gconf’ branches need more QA and documentation work, but they’re looking good and will definitely be featured in java-gnome 4.0.7.

You can download java-gnome from ftp.gnome.org or easily checkout a branch from ‘mainline’ using Bazaar:

$ bzr clone bzr://research.operationaldynamics.com/bzr/java-gnome/mainline java-gnome

Well, now that I have this out of the way, I can finally stop worrying about having so much unreleased code and get back to the business of doing what I do for a living.

On a personal note, I mentioned that much of this coverage was driven by one of our legacy apps. About half way though this cycle, however, we decided we would be abandoning that program. Needless to say, it was more than slightly depressing to be putting so much work into writing new coverage for java-gnome in order to port such a large codebase in the certain knowledge that the application was not going to be resurrected after all, especially as we have not yet managed to raise any revenue to offset our costs in taking on the Java bindings for GNOME.

Cognitive Dissonance.

Nevertheless, I kept at it largely because getting that app to run again represented a good test of the quality and comprehensiveness of the Java bindings. It needed doing, and that has ultimately been the motivation behind all our work re-engineering java-gnome. I gotta say it was wonderful seeing that program come back to life bit by bit as the errors slowly fell away as missing classes and methods were added to the library. That monster running again after almost two years represents the 4.0 version of java-gnome having surpassed the level of coverage that we used from the old 2.x version, and that’s something to be very positive about indeed.

Of course, now all I have to do is to continue to resist the temptation to go back to working on that beast. :) No, better things to be about.

AfC

Category Specific Feeds. Use these links for an RSS or ATOM feed limited to this category and its descendants. Technorati Profile