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

drepper-on-memory, posted by Andrew Cowie in /andrew/software/research at 23:39, 25 Feb 2008.

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.

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

java-gnome-4.0.6-release, posted by Andrew Cowie in /andrew/software/java-gnome at 12:54, 12 Feb 2008.

---

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

---