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

java-gnome 4.0.15 (16 Mar 2010)

Radio things

This has mostly been a bug fix cycle with numerous internal quality improvements being made. A few developer visible API additions have been made, summarized below.

Unified radio handling

There are a number of controls in GTK that exhibit the “radio” behaviour of being in a group of which only one can be selected: RadioButton, RadioMenuItem, RadioToolButton and RadioAction. We originally had a class called RadioButtonGroup which was used when constructing RadioButtons to indicate which group they were a member of. In introducing overage of the other radio types, Guillaume Mazoyer implemented a generic grouping class called RadioGroup which is now used for all the radio types.

XDG utility functions

A number of utility functions (aka static methods) were added to Glib allowing you to access the various user and systems directories as specified by the XDG specification. These are Glib.getUserConfigDir(), Glib.getUserDataDir() and friends.

Miscellaneous improvements

Better control of positioning when popping up context menus; you can specify co-ordinates when calling Menu’s popup().

The no-arg “convenience” packing methods we invented for HBox and VBox were causing more trouble than they were worth because people we not understanding the implications of the “default” packing values. So these are deprecated; the full four-argument packStart() and packEnd() have been present for a long time and are to be used in preference.

Serkan Kaba spent a bit of time working with the text version of the ComboBox API. Apparently no one had needed removeText() so he added that.

A number of improvements to the coverage of GDK’s event masks were merged. This is work originally by Vreixo Formoso necessary to support the Widget.MotionNotifyEvent signal, though it has use in other applications. Widget now has addEvents() and setEvents() to this end.

Finally, Guillaume needed to handle selections in IconViews. The API is similiar to that in TreeView, but doesn’t use the same TreeSelection helper class; the methods are directly on IconView. Boo for asymmetry. Anyway, we’ve exposed isSelected() on both TreeSelection and IconView so you can find out if a given TreePath is currently selected.

Better initialization checking

Logic checking that the library has been properly initialized has been refactored, making it harder to accidentally misuse java-gnome when getting started [or when starting a new program after you’ve been using the library for years and forgotten the basics :)].

Last but not least, a number of bug fixes; one in Enchant was developer-visible; Enchant.requestDictionary() now returns null like it claimed to if you request an unknown dictionary. Nice catch, Serkan.

All the source files have the full (ie traditional) GPL v2 header text now; the files comprising the library as used at run-time have GPL headers text + the Classpath Exception text. Needed to be done. Makes for a large diff this release, but makes the Ohloh‘s page for java-gnome happy too :).

You can download java-gnome’s sources from ftp.gnome.org, or easily checkout a branch from ‘mainline’:

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

though if you’re going to do that you’re best off following the instructions in the HACKING guidelines.

Enjoy!

AfC

I likewise discovered Inconsolata not too long ago (it was packaged in Gentoo and I was really pleased to discover it also available in Debian), and have been using it as the constant-width font in Quill and Parchment for program listings in technical writing.

We all tend to get obsessive about things we like, and so of course I tried it as a terminal console font. Interestingly, after a brief consideration, I decided not to use it for terminals and gedit and such. Deja Vu Sans Mono is still the king for that, especially if you’re using Deja Vu Sans and Deja Vu Serif for the rest of your UI; it means that the visual consistency across your desktop is really awesome.

Inconsolata doesn’t have anything even remotely close to the kind of Unicode coverage you need in your full-time constant-width font, and when fontconfig does a fallback it looks awful because Inconsolata’s metrics are so different from others. That’s all ok; Inconsolata is meant for program listings, and looks incredible on paper.

Anyway, Federico noted that bold didn’t work when specified as a FontDescription, it doesn’t come up bold me either when I tried to do so via a bold PangoAttribute. But if you use Wouter’s Specimen, it shows up fine (on an Ubuntu box, anyway):

So there’s a bug in our stack somewhere.

AfC

Update

Or not. I just reread the JavaDoc for the FontDescription constructor, and lo and behold relearned what I wrote there in the first place. To get bold Inconsolata you just need to use a ',' in the right place:

    desc = new FontDescription("Inconsolata, Bold 8.0");
    ...

and my Cairo drawing code on screen in a XlibSurface shows bold. Great.

But nothing is ever simple. I ran the same drawing code out through to a PdfSurface, and no bold. What the hell? There’s a bug in our stack somewhere. {sigh}

In my original post, I misattributed Specimen… it’s written by our very excellent Wouter Bolsterlee, uws on IRC. Sorry!

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

java-gnome 4.0.14 (16 Dec 2009)

You have to compose in order to enchant

Access to Enchant spell checking API

Coverage of the Enchant spell checking facade (which was already an implicit dependency arising from our GtkSpell coverage) is now included in java-gnome. It’s a lovely library with a simple to use API which in turn fronts for various back end spelling providers.

More detailed input handling

GTK’s handling of complex input methods is extraordinarily powerful, and of course present by default in the Entry and TextView text entry Widgets. If you’re doing your own text based work, however, you might need to capture the results of an input method being used to compose characters or words. InputMethod.Commit is where the result of a compose sequence is captured and delivered to the application.

We’ve also made numerous improvements down in GDK where events are processed; as a Java library we represent many naked low-level native entities with strongly-typed classes, and have improved our coverage here, notably with new Cursor constants representing the common use cases of changing the pointer.

Improved text rendering

Other minor improvements are present across the text rendering stack, notably with the ability to introspect where a Pango Layout has made its line breaks when wrapping via LayoutLine’s getStartIndex() and getLength() methods.

Guillaume Mazoyer finished up a work by Serkan Kaba resulting in us having coverage of the special LinkButton subclass of Button which can be used to present clickable URLs.

You can now create custom PaperSize objects, which is handy if you need to use Cairo to output PDF documents with a non-standard paper format.

Other changes

You can now use gdk-pixbuf to query an image on disk for its dimensions via Pixbuf getFileInfo() function calls.

There were of course miscellaneous improvements to various long established core classes, mostly fixing typos.

We now have the methods necessary to have ImageMenuItems actually show images (there’s a GNOME bug whereby suddenly icons are not showing in menus. So you need to either explicitly tell an ImageMenuItem that it should always show its image, or use the global Settings to say that Menus and Buttons should always have their icons showing).

The internal initialization sequence has been tweaked to ensure that GLib’s threads are initialized before anything else. This means java-gnome apps will work if glib 2.22.3 is installed; this is a workaround for bug 603774.

Headless testing

For a long time we’ve had to be careful in our test suite not to do anything that would cause a Window to appear or otherwise popup while the tests were running. But some for some test cases this is unavoidable, especially if the main loop needs to cycle. We now run the java-gnome test suite within a virtual X server (ie Xvfb), and as a result distros packaging the library can run the test suite on their headless build servers if they wish. There’s a new base class for java-gnome TestCases needing to run in this environment.

Looking ahead

What’s ahead for java-gnome? That’s always a good question. At this point java-gnome provides a comprehensive API for development of user interfaces suitable for the GNOME desktop, and it’s incredibly rewarding to see people using the library for their own programs.

Development of java-gnome has continued pretty steadily, driven by people finding they need additional features from some of the underlying GNOME and FreeDesktop libraries we already expose. As a community we also work to fine-tune the performance and quality of the library through continuous improvement of the code base and its algorithms. There are also people quietly working on experimental coverage of more unusual libraries such as GStreamer and Clutter which is pretty exciting to see.

Anyone using java-gnome are always welcome to join us in #java-gnome to ask questions or just hang out! So happy hacking, and see you soon.

You can download java-gnome’s sources from ftp.gnome.org, or easily checkout a branch from ‘mainline’:

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

though if you’re going to do that you’re best off following the instructions in the HACKING guidelines.

Enjoy!

AfC

It turns out that someone removed the icons on purpose!

It didn’t attract that much attention at the time, but this setting was changed by the small group who maintain GNOME Control Center. They claimed that text-only interfaces were better. Hm. That doesn’t seem right, but interesting choice on their part. Fine. So you start hunting around in System -> Preferences to find the place where you can return your GNOME desktop to normal.

There isn’t one.

The usability of icons

In the GNOME community, we’ve gone to immense effort over the years to get people to use the proper stock GTK icons in menus and buttons so that the user experience is consistent across applications. They’re a significant cue that aids navigation. Meanwhile non-GNOME applications poorly ported from other platforms often violate this consistency (Eclipse {cough}). So suddenly lacking icons the entire desktop looked ghetto.

The whole debate about what the user experience should be was an interesting one, but it seems a user experience change of this magnitude qualifies as just the sort of thing we don’t do to the huge communities of people using our Desktop during a stable release series. We have GTK 3.0 and “GNOME 3.0” coming up, and surely those would have been the appropriate contexts to propose such change, and the right place to trial landing it.

The part that really puzzles me, though, is that after the people who made this change were (politely) asked if they could point to the usability research that makes them think that text only menus are better, they (politely) replied with reference to a respected source in HMI design, Jared Spool. Reading that page it indeed says that text only is better than icon only. But right before that, however, he indicates that the combination of icons-and-text is more usable than text-only, with the further emphasis being that consistent positioning (ordering in menus) of those illustrative aides being what really what matters. Which seems to make it strange that text-only was just rammed down users’ throats.

Find out what’s broken and fix it

That they changed something is NOT the issue; at the end of the day it’s the people who do the work and write the software who set the agenda. But something this widespread seems like it ought to have been discussed on the usability and accessibility lists. And that’s the problem; there’s no mechanism requiring that.

It’s not the GNOME Control Center hacker’s fault that this became such a sore point for the rest of us; they were in a position to change something they wanted to change and so they did so. That’s just another day in Open Source land. But in GNOME there’s nothing that enforces the GNOME Human Interface Guidelnes. If a change like this had been proposed as a change to the HIG and if following the HIG was mandatory then clearly people would have had a good focused discussion about user experience, we could have come to a consensus (or “Usability Team” could have made a decision), the HIG documents would have been patched as a part of that, and then we could all get with the program.

The GNOME “Release Team” puts new module proposals through hell to be accepted as a part of GNOME, with endless discussions about what the user experience will be. Libraries underneath the desktop work incredibly hard to maintain API and ABI compatibility across releases. We try to remember that corporate IT departments just want gentle improvement between their upgrade decisions, rather than having to deal with a wrecking ball every six months. So we all know the importance of not screwing the user around.

But unless we find a way to apply the same rigour to maintaining UI standards like we do to managing the internal technical aspects of our platform, it seems we’re doomed to keep breaking the consistency of our users’ experience (and more to the point, jerking the chain of all the people who work hard to install and support the systems that our users run). How to do that while still enabling people to innovate is the hard part, but surely requiring people to follow the HIG and making that document the heart of user experience debate would be a step in the right direction.

Meanwhile, lets fix your desktop:

Workaround: users

The Control Center hackers removed the “Interface” tab from gnome-appearance-properties which is a shame since it would have been a lovely place for the user to say whether or not they wish icons in their menus and buttons.

It was pointed out that this is all still controllable by the user… by changing GConf settings. I think most of us would agree that is the very definition of what normal users aren’t expected to be doing.

The GConf keys are:

/desktop/gnome/interface/buttons_have_icons

and

/desktop/gnome/interface/menus_have_icons

So to fix your desktop to be consistent with previous GNOME releases, you need to run:

$ gconftool-2 --type bool --set /desktop/gnome/interface/buttons_have_icons true
$ gconftool-2 --type bool --set /desktop/gnome/interface/menus_have_icons true

You’ll definitely need to repair your system like this if you’re working in applications such as Inkscape that have huge numbers of items in their menus; they become really difficult to tell apart if you don’t have the pictorial aides to help you identify the action you’re looking for.

Workaround: code

It turns out GtkImageMenuItem has a new property "always-show-image" for really important icons, ie where “the menu item would be useless or hard to use without it”. The idea is that application programmers using GTK manually need to call this for all the menu items where the icons is really important and you actually want the icon shown in the menu item (Given that you have to go some trouble to construct a GtkImageMenuItem rather than just a normal GtkMenuItem, I would have thought that that emphasis would have been a given. Alas). I just added a setter to java-gnome:

    quit = new ImageMenuItem(Stock.QUIT);
    quit.setAlwaysShowImage(true);

There are also GtkSettings "gtk-menu-images" and "gtk-button-images" which can be used to set the property globally in an application programatically or via .gtkrc:

    settings.setMenuImages(true);
    settings.setButtonImages(true);

Judging by the howls of protest, not too many people had noticed the importance of these properties, and so no one was setting it in their code. Assuming that the new default is likely to stand in the GNOME >= 2.28 era, then indeed we’ll all have to be doing this a lot.

Setting defaults

Thinking about this from the perspective of a bindings hacker and sometimes application developer, it all makes me realize the importance of exposing setters for properties, and calling setters even when the value you are setting is the default. It’s tempting to think “oh, I don’t need to call that method, it’s set by default”, but as episodes like this demonstrate, relying on defaults isn’t very reliable.

AfC

Usually I see with crashes because of something I’ve done wrong in binding an underlying GNOME library from java-gnome. So I bisect & printf() my way down until I can find the thing that causes it, read the docs, and hopefully figure it out.

Recently, however, I’ve been getting crashes somewhere deep in libpangoft when my the app is first loading or worse just sitting there and I’m not doing anything more onerous than moving the cursor around a TextView. This is still likely due to something I’ve done wrong in my code or in the bindings layer, but when it’s not happening deterministically or on demand it’s hard to even begin to analyze the problem.

The OpenJDK HotSpot VM (formerly the Sun HotSpot VM) has a pretty good SIGSEGV handler; it does its best to show you what the C library call was that died, and what the Java and C call stacks were leading up to the crash. You may have seen them around as hs_err_pid10733.log and such [I wish it would just spew that out to stderr instead of troubling to write a file, but anyway].

Strangely, the only line I’m getting when reading the crash report is:

C  [libpangoft2-1.0.so.0+0x17687]

no other stack frames. Which is a bit strange, and decidedly unhelpful. So I’m going to need to try a bit harder to get a backtrace, it seems.

Getting a native C stack trace of a Java program with GDB

Much as I otherwise feel GDB is the most horrendous user interface in the history of civilization (ok, maybe second only to GPG’s command line interface), it does do one thing extraordinarily well and that’s stack backtraces of crashed programs. These days one normally runs one’s program in gdb, induces it to crash, and then runs bt:

$ gdb ./program
(gdb) run
SIGSEGV caught
(gdb) bt

And you get your stack trace.

That’s a bit of a pain with a Java “program” because as mentioned the process running is a Java Virtual Machine (and because invoking java is … almost as bad as GPG’s command line interface):

$ java ... gobbledygook ... package.Class arguments

Usually people put their invocation line in a shell script along with various environment setup and so on:¹

$ ./script arguments

and off they go. The complication is that’s not really easy to use with GDB, since you need to invoke gdb on the binary executable (the JVM) and then, once GDB is finally up, tell it to “run” that executable with a bunch of arguments. Which means you’re back to the gory mess:

$ gdb java
(gdb) run ... gobbledygook ... package.Class arguments
SIGSEGV caught
(gdb) thread apply all bt

which is incredibly tedious for casual use.

But the old fashioned 1980s way of using a debugger is to get a “core dump” of memory into a file called core and to run GDB on that. Just set your shell to core dump, then go back to running your program as normal:

$ ulimit -c unlimted
$ ./script arguments
Aborted (core dumped)
$ gdb java core
(gdb) thread apply all bt

and our stack traces will spill out in great gory detail. Hooray!

Incidentally, if you want to play with GDB and see what a HotSpot JVM is up to, then you need to induce it to crash; one way to do this is to send it a signal, say SIGSEGV or SIGBUS:²

$ kill -11 10733

Yeay, Open

The real point here is that with Sun having open sourced Java and it’s HotSpot VM implementation, we can now build Java ourselves and include debugging symbols [on Debian Linux, for example, install package openjdk-6-dbg along with the symbols for the various libraries in the GNOME stack, libgtk2.0-0-dbg and so on]. This means, at long last, we can actually run Java under GDB — something we weren’t able to do when Java was proprietary — and get lovely backtraces when it thunders in.

Yeay for crashes.

AfC

¹ Which is why people put this invocation into a shell script, which makes it even harder to debug because you’ve got to run ps axww or whatever to try and get the full command line used to run the program. {sigh}, but fixing this will have to wait for another day.

² Bernd Eckenfels suggests avoiding SIGSEGV as apparently he believes this is caught in some places and rethrown as NullPointerException. I’ve never observed that, but I thought I’d mention his advice to use SIGBUS instead.

Comments

• Josh Triplett wrote mentioning that he likes to use SIGQUIT to get his C applications to core dump, since you can trivially generate that signal from the console with Ctrl+\. What he didn’t know was that Sun’s Java VM has always had a handler for SIGQUIT which prints a stack trace for each currently running Java thread (which is useful when trying to debug deadlock issues, but it’s the Java-side call stack only, not the native frames).

• Mark Wielaard mentioned a nice trick to attach to a crashing hotspot JVM to work around any core file limitations:

  java -XX:OnError="gdb - %p" <arguments>

• He and James Henstridge also note that having the “live, but almost dead program” around sometimes makes things a little easier on the debugger (as opposed to relying on a core dump). James suggests computers are fast, and just running all your [problem child] programs in gdb all the time. Fair enough, although in my case with such a hard to reproduce crash, I think I’ll wait on a core dump.

• Mark let me know that on Fedora you can get debug symbols for any package you are trying to inspect. If you do debuginfo-install java-1.6.0-openjdk (in this case) it will pull in every dependent debuginfo package also! He also notes that this crash in question might actually be a Pango problem, and cites this Fedora bug.

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.13 (27 Aug 2009)

Unicode. It’s bigger than you think.

This is a bug fix release to address a serious weakness in Java’s handling of Unicode characters.

Unicode handling

It turns out that Java’s chars are not pure Unicode codepoints. Most people know that Java String objects are arrays of Java chars, but in aggregate they are encoded in UTF-16 in order to deal with the fact that there are Unicode characters whose index is higher than 0xFFFF and which need more than two bytes to identify them. It’s a problem that an application developer has to deal with if they’re using high-range “supplementary” Unicode characters, but wasn’t something that would break java-gnome…

Except it turns out that the Java VM does not do UTF-8 translation properly. It has a hard wired limitation preventing it from writing out UTF-8 sequences longer than 3 bytes. Who knows what crack they were smoking when they decided that one. But things like TextView / TextBuffer work in characters, so we need characters. (actually, they work in UTF-8 bytes, but the offsets in our public API are the characters variants).

Luckily, we can get at the raw UTF-16 arrays backing Strings, and so in combination with GLib’s character set conversion functions, we’ve been able to redo our string handling internally so as to have correct treatment of Unicode codepoints. Lots of testing.

This surgery was almost entirely internal; Strings returned by java-gnome methods are of course still Java String objects.

New coverage

This release also features the work of Guillaume Mazoyer exposing some of the new features available in Entry Widgets, including displaying icons and showing progress bars in the background. This compliments other minor enhancements to various miscellaneous classes.

With this release, java-gnome now requires GTK 2.16 or newer.

This release is already packaged for Gentoo and Ubuntu, which is sweet.

You can download java-gnome’s sources from ftp.gnome.org, or easily checkout a branch from ‘mainline’:

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

though if you’re going to do that you’re best off following the instructions in the HACKING guidelines.

Enjoy!

AfC

For one thing, they usually say it’s going to be:

“Fine.”

Fine?

To me, that implies “hardly a cloud in the sky, bright and sunny, and warm. Head for the beach, yo!”. But it doesn’t seem to mean that here.

My Dad in Toronto a specialist in amateur weather data gathering. Yes, that means what you think, but he’s also a volunteer team coordinator in the provincial emergency management and disaster response organization, so I don’t mind him getting all excited about dark and stormy clouds. But Dad, could you maybe please just keep your eyes on the road instead of looking for the tornado anvils? Thanks dude! You’re a star. Now get me to the airport. I’ve got a plane to catch. Preferably before the tornado gets here.

So I’m always getting messages like “Good morning Andrew! According to crystal-ball-forecasting.com here, it’s a fine day for you today!” Well, thanks for checking, but he means “nice” and no, it’s not nice today, actually.

Since Dad is a weather nut, I’ve been paying closer than normal attention to the forecasts here. And there’s something strange going on: the weather forecasts don’t ever seem to have anything to do with the weather. I think the problem is that Crystal Ball Forecasting Inc get their data from the Australian Government’s Bureau of Meteorology, who appropriately enough seem to use a crystal ball for their weather forecasting. Don’t believe me? I shall now demonstrate.

The quoted portions are from the Bureau of Meteorology’s morning forecast on the day given, usually leaving out the part about what the wind was expected to be. Copyright © 2008-2009 Commonwealth of Australia in right of Her Majesty the Queen. The comments are from my emails conveying the weather forecast to my Dad on those days.

23 Sep 2008

Forecast for Wednesday:

“Cloudy. Isolated showers or drizzle but fine for the most part.”

What the hell is that supposed to mean? “Fine”? What are they smoking?

1 Nov 2008

How’s this for a weather forecast for Saturday night:

“Overcast with the chance of a shower, otherwise fine.”

So do I need a rain jacket or not?

10 Mar 2009

“Chance of a shower or two, more likely during the morning and then again at night. A cloudy morning, but sunny breaks developing during the day.”

Of course, it was bright and sunny all day.

3 May 2009

The forecast today:

Partly cloudy near the coast with a few showers, clearing later. Mostly fine with lengthy sunny periods in the west.

I would have taken that to mean it’s raining out west, except that would imply it was raining over the city’s water supply catchment area, which never happens. So they were probably right about it not raining there after all.

26 May 2009

The weather:

“Fine and mostly sunny until a shower or two develops”

really.

2 Jun 2009

As at 07:30, the forecast for the day is:

“Cloudy with a few showers, and periods of light rain developing.”

I’m glad you clarified that.

19 Jun 2009

“A few showers. Cloudy periods. Morning fog patches.”

Since it is nice and sunny out, I think I’ll go out for a coffee in the park now.

15 Jul 2009

“Cloud increasing and a shower or two developing in the afternoon with the chance of a thunderstorm and small hail.”

Which is clearly why it is sunny out right now at the cafe where I’m sitting.

I gave them the benefit of the doubt, though: it does “change” here sometimes, so I most certainly brought my raincoat with me this afternoon when I went a wandering. Nothing to do with the Bureau of Meteorology; that’s simply a Murphy’s Law thing.

That evening

“A shower or two, with a chance of tsunami. Light to moderate south to southwest wind.”

Which admittedly is nothing to joke about, but given their track record…

4 Jul 2009

For once the official forecast was quite dull. So I improvised:

“Lengthy sunny periods, except for heavy morning showers, afternoon fog patches, chance of an evening thunderstorm. Possible snow overnight.”

Dad missed my note saying that I was joking; he simply commented “seems par for the course”.

Fine

There is a happy ending to this story, though: I finally found out what “fine” meant!

Apparently they’re trying to say:

“It won’t rain today”.

Pardon me for being underwhelmed.

AfC

Comments:

James Andrewartha wrote in suggesting a page of terms used by BOM, including “fine”. Thanks! Doesn’t excuse the fact they’re still using the word differently than the rest of the English speaking world, though :)

From an online exhibition sponsored by the Royal Institute of British Architects.

And you think you’re having trouble keeping your life straight.

AfC

Havoc Pennington wrote a classic essay almost a decade ago about working on open source software. A lot has changed in 10 years, but his advice has surprising endurance:

Don’t start by launching your own project… it’s more educational to read and learn from other people’s code.

If you haven’t lurked and participated in a free software project, you won’t know how things are done and you’ll have an awful time trying to run your own…

If you do start a project, the all-important thing is to write code. You have to code enough to make the app useful pretty much by yourself; this can be months or years of lonely work…

When it comes down to it, writing a free application is a huge amount of work. If you’re writing your own, schedule 10-20 hours per week, at least… And schedule those 10-20 hours every week, for the foreseeable future. If you can’t commit this much time — don’t even bother starting the project. If you can’t write code, ditto.

It takes about a year

It takes about a year to write a serious application. A year! Sure, it’s easy to knock off a proof-of-concept or a mockup, but once you get down to the business of making all the internals actually work, ensuring it is well tested, and making it build for other people it all just becomes a long grind.

And frankly, that year is just to get far enough to know whether the thing is going to fly or not. It takes somewhere between two and three years to get a serious application to the point where it’s polished and well-rounded enough where other people are able to use it.

And as Havoc points out, then if your app becomes widely adopted you’re in for years and years of continued involvement.

Why on earth do we do it?

Writing software, writing poetry

This week a friend introduced me to Jacket Magazine, a poetry and literature periodical. Tons of cool & eclectic stuff. It’s published entirely online, and is clearly a labour of love. Early on the founder & editor, John Tranter, wrote an essay for the about page. The piece mostly focuses on the economics of periodical production and how the internet has opened revolutionary possibilities for the distribution of literature. Hot topics today, right? Not bad for a piece written in 1999.

The best part, though, was when he tried to describe his motivation:

The main cost is my time; which means I don’t get much poetry written these days. … it takes up most of my waking life. Why do I do it? Jacket is hard work, and I like hard work. I enjoy editing the poems and articles and taking photos of people and designing the pages, and I even enjoy writing the HTML that underlies the pages. Jacket exercises all my various talents - and it’s fun.

It has also enlarged my circle of friends by a factor of about ten. And I feel I’ve enabled a lot of writers to find a wider international audience for their work, especially younger poets. I received a lot of generous support and assistance when I was a young writer, and it’s good to be able to give something back.

10 years later, he and his contributors are still at it. Beautiful.

I’m not a poet, but the compulsive dedication that he talks about resonates.

I am ashamed to admit that of the five or so major software projects I have initiated since I returned to writing open source in 2002, only two of them have made it past the “1 year” proof-of-concept point, and only one of them has reached the “usable by real people” stage — indeed it has taken over 3 years, and that project is a library, not even an end-user application!

This emphasizes a point that the agile development community have been making for a while now — you have to get to the point of your app being usable by {you, your customer, whoever} as unbelievably fast as you can. If you’re not able to enjoy the fruits of your hard work, then you’ll likely reach the point where you’ve put tons of effort in and it’s still a demo harness that you can’t actually use for what you wanted to use it for. Live and learn.

Or maybe not :)

I’m at it again; I’ve got another one brewing, and it’s passed the 1 year mark. The competing pressures are almost overwhelming. One the one hand is the excitement that it’s starting to come together, and that drives me forward. But at other times there is intense frustration when I discover yet another bug and when it feels that the thing is no closer to being usable (by me, let alone anyone else) than it was months and months ago. Sometimes you just want to let it all go.

And I have no doubt that it will be at least two more years before it reaches the level of polish and general usefulness that is merely the starting point for other people to consider using this program.

What in God’s name am I doing spending time on this?

The demon that drives us

I was trying to explain all this to someone in a bar a few weeks back, and she asked that very same question.

Are you doing it to make money?

Well, no.

Then why are you doing it?

Well, the coding I do has paid off, at least sort of. Most of my software architecture work is consulting to large companies, but all the experimentation and new ideas that drive those engagements comes from my open source work. And some of my clients have found me through my public hacking.

Oh, so, it’s a promotional activity?

Well, I suppose it ends up that way, but that’s not why I’m doing it. It takes too much time to justify that way. Perhaps in the long term people will use my software and think well of me for having written it. Probably not, though; likely they’ll just bitch about how it doesn’t do this or that that they think it should. Doesn’t matter, I’m not really doing it for them.

Who are you doing it for?

Me.

For three years!

Hm, yeah, probably longer.

So you’re not going to make any money out of this, you aren’t building your reputation with people who hire you, and you may not ever finish it. Why are you doing it?

and I finally found an answer that made sense. The right answer:

Because it needs doing.

Needless to say that was pretty much the end of that flirtation. Apparently non-materialism isn’t sexy. :)

Doesn’t change the fact that it really is the reason we do it. It needs doing.

As for the thing I’m working on? The feeling of accomplishment that comes when I show people screenshots of my work is undeniable. The code inside’s not bad, not bad at all. And I’m actually dogfooding with it now (ok, ok, almost). I think this one is going to fly.

At last.

AfC

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.12 (24 Jul 2009)

Being Uniquely Notified while Spelling the Sources you are Viewing is good for the soul.

In addition to ongoing improvement in our coverage of the GTK widget toolkit, the next release of java-gnome begins to realize our vision to offer coverage of the broad suite of libraries making up the GNOME desktop.

New Coverage

The TextView text editing Widget has received two significant capability boosts. With the work of Stefan Schweizer, we now have coverage of the powerful GtkSourceView library with its impressive built-in multi [programming] language source highlighting features.

And with the contribution of GtkSpell coverage by Serkan Kaba, we can now offer spell checking in TextViews as well.

Two other GNOME libraries feature in this release. Serkan also contributed excellent coverage of LibNotify, enabling an application to create and send popups to be displayed by the desktop notification mechanism.

And, we expose LibUnique, which offers DBus-powered machinery enabling a developer to ensure only one instance of their application is running.

Continuing improvement

Lots of minor changes and enhancements throughout the core GTK libraries. Highlights include improved mouse button handling, filtering when choosing files, and further refinement to Pixbuf. Thanks to Peter Mossveld, Kenneth Prugh, Vreixo Formoso, Serkan Kaba.

Finally, thanks to Guillaume Mazoyer we now have coverage of EntryCompletion, the feature of Entry Widgets whereby available possible completions are offered to the based on characters the user has typed so far.

Looking ahead

There are a number of people working on various branches — some small feature extensions, and some major coverage additions that add signifant capabilies — but which haven’t quite made it to the point where they can be merged into java-gnome. We’ll see how these pieces of work fare in the coming months, but nevertheless the Java bindings for GNOME have reached a significant level of maturity and we are pleased to see people starting to use them for serious application work.

This release is already packaged for Gentoo and Ubuntu, which is sweet.

You can download java-gnome’s sources from ftp.gnome.org, or easily checkout a branch from ‘mainline’:

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

though if you’re going to do that you’re best off following the instructions in the HACKING guidelines.

Enjoy!

AfC

    An undersea earthquake of magnitude 7.9 at Latitude 45.960S
    Longitude 166.470E occurred at 07:22 pm EST on Wednesday 15 July
    2009 near OFF W. COAST OF S. ISLAND, N.Z.. Sea level
    observations have confirmed a tsunami has been generated.

“Alert” is actually a bit of a misnomer; it was in the weather forecast. I only accidentally noticed the warning when I happened to check GNOME’s trusty little weather-applet wondering whether it was likely to be sunny the next day. So it’s great that I saw the alert there, but, if there’s a warning then I think gnome-applets needs to freak out a little to get the user’s attention. Maybe a different current-weather icon in the panel? Or better yet, a libnotify popup (“run for the hills” is a little more important than “your battery is low”)?

Anyway, as all this was going on, I was curious about the obvious question: “how do you detect such a thing a tsunami wave in the deep ocean?” One of the things about such energy is that although real tsunami become disasterous (ie huge) when they hit shallow water, out in the deep ocean they are not much more than a tiny ripple. Hard to notice amongst swell and chop.

Various national agencies have tsunami detection instruments floating around out on the high seas. These graphs show the data as gathered from buoy 55015 on the evening of 15 July:

which doesn’t appear to mean much, until you realize that the monitoring systems switch to transmitting high-resolution data when they detect an event; the longer time base data around the event above looked as follows, and suddenly it becomes clear that they noticed something abnormal:

Snapshots taken from the National Data Buoy Centre real time data page as presented on 15 July 2009; if you dig around you can find historical data there too.

It would appear that general sinusoidal trend line on the above is normal variation; sure enough if you look at today’s 15-minute data,

it’s pretty clear that normal measurement is tidal variation. Huh.

Column height

Anyone who has spent time out on the water knows full well that the surface is insanely variable; that got me wondering how they measure the waves going by (more to the point, how do they notice a tsunami wave a couple centimetres in size out amongst the randomness of wind driven chop and ocean swell?).

Well, it turns out that these at-sea buoys are not taking soundings from the surface as they bob around. The instruments are placed on the sea floor (!) and measure the hight of the water column as inferred by the water pressure.

Image from the NOAA National Data Buoy Centre page about DART buoys.

Note to super-tanker drivers: please don’t hit these. Thanks.

Never cry wolf

Thankfully, this earthquake and the associated ocean wave it generated did not result in a destructive tsunami when it reached the coastlines in the region. The fact that the authorities raised a high-profile alert for what turned out to be a non-event, however, raises the risk that the next time there is a tsunami wave detected the warning will be ignored by the news media.

The essential message remains, though: detecting waves is one thing (and impressive!). Forecasting destructive potential is another, and that part is still a very grey area. Hopefully people will accept this.

AfC

Why are there unicode characters for roman numerals? ie, Why is U+2167 'Ⅷ' better than VIII? And, whoa, thank God that there’s U+216F 'Ⅿ' there, because otherwise I’d have to use the letter 'M' to write ©MMIX.

As we were chatting about this in #gnome-hackers, Xan Lopez found a wikipedia entry about it which seems to say “Only for compatibility” & “do not use”. I can handle that.

AfC

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.11 (1 May 2009)

This is a bug fix release.

We made a few mistakes in our handling of the PangoAttribute structures’ memory which resulted in VM crashes [unfortunately, the normal GNOME way of debugging things is to SIGSEGV. That’s fine for a C program but Bad™ for your average Java Virtual Machine as it takes out the entire process. We therefore work rather hard to avoid — or at least trap — this sort of thing]. Releasing corrections for these bugs was a priority.

Concurrently a significant internal improvement in our handling of accumulating Attributes into AttributeLists was made. While this is not user visible per se, we were able to drop the requirement that the text you were formatting already be in the Pango Layout before assigning the range that the Attribute would cover. You also no longer need to pass that Layout to setIndices() when building up Attributes. This makes things a great deal easier if you are simultaneously aggregating the text and assigning markup.

Martin Garton contributed some documentation quality improvements and new coverage. Serkan Kaba made some minor fixes to ensure the unit tests run in a Turkish locale. And as ever there are small incremental improvements to various classes, including a number of additional properties exposed care of the work of new contributor Thijs Leibbrand.

Looking ahead

This was a brief cycle; as noted we’re mostly pushing some bug fixes. Meanwhile there are a number of significant branches underway by various hackers; which, hopefully, will feature prominently in the next release.

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

though if you’re going to do that you’d best follow the HACKING guidelines.

AfC

AfC

Anyway, one of the pieces of this system is MQ (which, in case you’ve not heard of it, is a very widely adopted — if somewhat cumbersome and archaic [not to mention proprietary and commercial] — enterprise message queue platform; no, you’re not missing much, and yes, there are open source alternatives). So the other day I was quietly investigating the sequence involved in doing an upgrade of an existing MQ installation. Along the way I came across a forum posting by someone asking a similar question to what I had in mind:

Q: Is is possible to move directly from MQ V5.3 to V7.0???

ie, skipping MQ 6.0. A reasonable thing to ask (even if they did overdo the question marks); these things are not always obvious and sometimes you have to go through an intermediate step. An experienced individual quickly replied:

A: Yes.

Which was terrific. An enlightening answer; to the point, authoritative, direct, and concise. Very helpful. Well done, and much appreciated.

I was certainly well satisfied at that point, pleased to be able to benefit from the shared wisdom of the global village. Our erstwhile original poster, however, under the mistaken assumption that the internet is a place where you can go to get people to do your job for you for free, continued on with a degree of persistent sticktoitiveness that one can only admire:

Q: What kind of challenges do we need to face during this process??

The answer wasn’t long coming:

A: Overcoming any fear of reading the documentation.

:)

AfC

“Sorry I’ve been out of touch; I’ve been away travelling on business.”

Interesting contrast. When I’m on business travel I tend to be more in contact.

Or, perhaps it’s just that I’m just more conscious of it, since one has to go to extra trouble to get email in airports, retrieve messages from hotel rooms, and find ways to make affordable phone calls (instead of succumbing to the temptation to just using your mobile at the cost of having to sacrifice a major organ to pay the roaming fees), etc.

I’ve noticed that it actually takes me going off trekking to get away from the curse of modern communications. Being up in the mountains is about as uplifting an experience as you get, but I’m sad to say that at least part of it must be the freedom from not having to check your email.

Half way up Grotto Mountain near Banff, Alberta, Canada.

Even harder — but essential — is that once in a while you need to have a no typing day. It’s should be easy to just decide not to do any typing tomorrow, but it’s astoundingly difficult to actually schedule such a day — especially when you’re an Open Source hacker and all you want to do with your spare time is work on the things you love.

But just as serious athletes need to take rest days to prevent over-use injuries, so does anyone who spends huge numbers of hours in front of a computer need to take a day off once in a while. We all need to give the tendons and fine motor muscles in our fingers, wrists, and forearms a rest. I’m not talking about “typing breaks” periodically though the day (I mean, jeesh, just get up and go for a glass of water), but an entire day with no keyboard, no mouse, and no being hunched over starting at the screen.

If you can, take a no typing day once every two weeks. It may not seem like much, but makes a wonderful difference to well-being. And since you’re not sitting at your computer, you might as well head up into the mountains instead. :)

That I had to type this is an irony that does not escape me.

AfC

3’s offering has two devices at the same price right now; the Huawei E160G and the ZTE MF627. I thought my friend had the latter and so bought that one. Big mistake.

E160G Bit older works great	MF627 Brand new doesn’t work

Do not get the ZTE MF627 device if running Linux. Stay away from it. Even after trying the usb_modeswitch hassles, it still does not present as the device as a GSM modem like it is supposed to. Tried it on two separate laptops; one running Gentoo, the other with Ubuntu’s “J” version on it. Spent the better part of a day researching and debugging the issue, but no joy on either. One person in London claims to have a similar device working, but comparing their lsusb and dmesg output, I’m not convinced the electronics in the one available here were the same; after doing a mode switch the miniSD adapter presents, but not the modem. Anyway, sure, maybe someday someone will figure out how to make it work here, but that’s not right now.

Even worse, people writing in places like Whirlpool cite chronic quality problems with ZTE devices. Clearly this is something to avoid.

I took the thing back to the store the next day and finally managed to get a refund which I promptly used to buy their other device (why they couldn’t just do an exchange was as puzzling to the poor guy in the store as it was to me. Whatever; they kept him on the phone for almost an hour while the corporate drones he had to call for permission made up their minds that it was ok to give me my money back).

So home I went with a Huawei E160G (which is what Peter had) and it worked perfectly, right out of the box, literally. Plugged it in, device properly recognized by USB subsystem and, after adding a “mobile broadband” connection with NetworkManager 0.7, it immediately started working. Pretty amazing.

You need to have the PPP stack built into your kernel and pppd installed (once upon a time we all had that, but most of us haven’t needed to do point-to-point over a dialup modem for years, so if you’re running a modern system with a custom Linux kernel you might not have it). The relevant kernel modules are “ppp_async“, “usbserial“, and “option“.

So a big hooray to the NetworkManager team and all the people working on the drivers that made this magic work. That NetworkManager seamlessly handles all the PPP configuration and dialing is brilliant.

Neat connection active icon.

And as for the lovely staff in the store, don’t let them tell you that their service doesn’t work on Linux — but do get a device that does.

AfC

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.10 (5 Mar 2009)

Sculptures made of letters

This release is a landmark, because it features coverage of the Pango text rendering library and so, along with our coverage of Cairo, brings us to a complete solution for drawing graphics with text — be they custom Widgets, PDF documents, or beautiful vector illustrations.

In addition to merging Pango work from numerous contributors, we have made massive improvements to our Cairo coverage, support for writing PDFs, and better access to the system Clipboard.

Drawing API improvements

We’ve done a huge amount of refinement to our APIs for the ever fabulous Cairo Graphics drawing library, including full coverage of matrix translations, rotations, and scaling and more integrated ways of setting the source pattern to be used in stroke, paint, and fill operations. Thanks to Kenneth Prugh for having seen this through and having done the lion’s share of the testing.

We’ve also had a number of improvements in the lower levels of GTK relating to image rendering. The gdk-pixbuf library contains a capable image parser and we can now feed it directly from a Pixbuf constructor. Thanks to new contributor Martin Garton for his hard work getting that tested and accepted.

Drawing graphics often also requires drawing text. This release features coverage of Pango, GNOME’s powerful text rendering library. Pango is not just about drawing mere glyphs; it also includes a sophisticated paragraph layout engine which gives us a capable solution for drawing text onto Cairo Surfaces.

Thanks are due to Serkan Kaba and Kenneth Prugh have both been really helpful testing; it was Vreixo Formoso who did the original leg work in April that identified Layout as the key class that we needed to concentrate on and cleaned up much of the underlying infrastructure.

As we were working on this we had occasion to continue the polish in and around the TextView / TextBuffer APIs, including a number of convenience methods for inserting text while simultaneously applying multiple TextTags, and supporting changing default fonts.

We’ve also modelled “notify signals” for when a property changes; see the TextBuffer.NotifyCursorPosition signal for this in action.

Finally, thanks to contributions from Zak Fenton and Kamil Szymala we have support for applications running in composited window managers to have transparent backgrounds — which is an exceptionally cool effect, even if it doesn’t have much to do with creating HIG compliant usable applications :).

Handling cut & paste

The GTK clipboard APIs are fairly complex, in no small part because the underlying implementations in X are really rather complex. Our coverage here in java-gnome is still fairly basic relative to that, but it’s been enough for people working on applications like text editors to write text to the system clipboard, get notification when the clipboard changes, and read text back out again.

Printed document support

The work on Pango noted above represented the essential machinery necessary to make effective use of Cairo’s PDF backend, and this has started us down the road of covering the GNOME printing APIs. You can now generate .pdf documents with java-gnome, and we’ve included an fun example showing this in action.

Thanks to Nathan Strum for permission to use one of his sketches in the example (you might find reading the blog where we found this interesting — it’s a fascinating exposé of a graphic artist in action).

Continuing improvement

Thanks to new contributor Stefan Schweizer we now have better coverage of signals relating to Notebook style Containers, and to new contributors Miloud Bel and Bruno Dusausoy for numerous small improvements in and around ProgressBar.

Miscellaneous documentation improvements and minor feature improvements always feature in our releases, with minor changes having accrued in many classes.

Just as important as new coverage is getting rid of cruft that we don’t need. Libraries like GTK and GDK are, like any other mature project, full of deprecated, obsolete, and unnecessary code — not to mention things that we just plain don’t need in a Java binding of these underlying native libraries. We’re already pretty good about not generating translation Java or JNI C code for such things; this release continues our refinements in this area with a considerable refinement of the .jar and .so which is ultimately what we ship.

Finally, it’s worth noting that java-gnome’s test suite is now 40 unit test classes with 186 individual test fixtures. Combined with over 30 screenshot generating programs and 17 example programs, we actually have surprisingly good test coverage of our library. It’s high time they — and more to the point the people who work hard to create such tests — got as much credit as the visible public APIs do.

Anyone can run the tests (and anyone wanting to submit a patch had better run the tests!); they’ve been accumulating since java-gnome 4.0.0; it’s just:

$ make test

and

$ make doc

If you’re working in Eclipse launch class UnitTests as a JUnit test suite.

Build improvements

We have some fixes from new contributor Przemysław Grzegorczyk ensuring we include the correct headers in a few corner cases. This came to us via work on a GNOME Love bug, which is a first for us. Thanks!

Meanwhile, the ever industrious Serkan Kaba has added some changes to ensure that our magically locating the native shared library component of java-gnome works properly even under strange and unusual conditions.

Configuration and prerequisite detection on Open Solaris is improved thanks to reports from new contributor Kamil Szymala.

Instructions for how to optimally lay out your branches when working with java-gnome have been moved to the HACKING file. People intending to hack on the bindings from Eclipse are really urged to set things up this way as it will make their lives much easier. Also, using the latest release of Bazaar (ie bzr >= 1.12) is definitely recommended — it’s getting really fast. We’ve upgraded our public branches, so you will need 1.9 at a minimum.

Note to those creating packages for distributions: java-gnome now depends on the current stable GTK (ie gtk+ >= 2.14).

Looking ahead

Coverage of Poppler, GNOME’s PDF rendering library is well along, but didn’t quite make it in time for this release. It could very likely feature in the next version of java-gnome, as might coverage of GConf, GNOME’s simple store for application configuration options. People are also known to be working on coverage of GtkSourceView, libwnck, and librsvg. We’ll see what gets contributed!

The most exciting part about java-gnome at the moment, though, is the number of people working hard on applications using it. It takes a long time to write a mature, well rounded, robust end-user program, but there are some pretty cool projects ticking away out there, and it has been terrific to see the authors of these projects joining our community.

Happy developing,

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

though if you’re going to do that you’d best follow the HACKING guidelines.

AfC

Eeek!

Now, laptops breaking are nothing special, and I do keep fairly regular backups. So I wasn’t that concerned about data loss. But in so far as the live-action style tutorials I give are less about formal presentation slides (though I do have lots of those as backdrop) and instead more “everyone gather around and watch Andrew play in his happy place”, suddenly losing my development meant that actually coding live in front of people was looking to be a bit of a problem.

My current laptop is from ASUS, and I’ve been very happy with it. That it fried, ok, fine whatever. But as we were now in Hobart, Tasmania I had a real problem. I needed a mainboard replacement. Fast. ASUS has service centres in Perth, Brisbane, Sydney, and Melbourne. But not Hobart.

Several people offered to lend me a laptop “for the presentation” which was lovely of them, but given that it wasn’t just me playing a slide deck but rather me needing my full development stack on board such a machine — and more to the point, me needing my system so I could get back to real work during and after the conference — my option space was very limited. Indeed, it took me all of about 3 seconds to realize that I was going to be on a flight (to Melbourne, probably) in about 90 minutes. Sure I could have couriered it and had it back in a “few days” but I patently did not have that kind of time.

Steve to the rescue

I was in the process of booking my flight out when Steve Walsh suggested that he might have a system I could use. At first it was borrowing one of the desktop machines they had around (yup, would have worked), but then he realized he might be able to lend me “the conference laptop”, which was a computer that Hewlett-Packard had donated to linux.conf.au a year or so ago. Josh wasn’t using it anymore, and Ben agreed I could use it. You guys are awesome.

As I was thinking about what I’d have to do to bootstrap and restore off of my closest available backup (on an SD card, but that’s a story for another day), I saw one of these lying on the table

and we suddenly had a very bright idea. Why not pop the hard drive out of my laptop and put it in that thing?

I had already considered putting my hard drive into the new laptop, but only for a brief moment. Even assuming it fit, I happen to have a very tightly tuned kernel and I knew was unlikely to have enough drivers to get booted on foreign hardware. Besides, the Linux installation on the new laptop was already running great.

But why not try putting my drive into Steve’s external USB enclosure? Would that even be possible?

Steve cracked his enclosure open and carefully extracted his drive. Then we started removing endless screws from my system and found our way down to the harddisk compartment and pulled my drive out:

To be honest, I would never have attempted such a thing, but Steve knew what he was doing (and more importantly, had all his tools handy). So, having taken the cradle off of my drive, we even more delecately then attached the enclosure’s logic board to my drive.

• Miracle #1: the connector from my drive fit the one in the enclosure.

(I gather that these things are “standardized” but still. The hardware you find in your average laptop is always wacky and weird. So I was pretty excited) With that done, we plugged it into the new system:

and to my supreme happiness,

• Miracle #2: the drive’s filesystems mounted to /media/disk

Hooray for the Linux kernel, HAL, the GNOME automounter, Nautilus, and everything else that made that work.

And then, even better,

• Miracle #3: whatever it was that took out my laptop’s mainboard did not zorch my hard drive.

Hooray! My data was all ok!

A little fiddling about to make sure there was now a user andrew with a matching UID on the Ubuntu system, and then, very simply:

$ rsync -av... /media/disk /home/andrew

Outstanding.

So thanks to the help of Steve and the others, I had my /home on this new system. And one of the magic things about the GNOME Desktop for the last few years has been them safely writing down everything you need to run, so pretty much instantly I had my happy place back.

The data, at least.

Comparing distros; comparing laptops

The one problem I still faced was that the system in hand was not configured as a development machine. I had to work out what the appropriate packages were for all the different bits and pieces I was accustomed to having.

One thing I really like about Gentoo is that they clued in long ago that disk space is cheap and that things like .h files don’t take up that much room. So when you install a package on Gentoo you get development tools, header files, debug symbols [if so configured], compilers, documentation, the works. I had forgotten that Debian and Debian derived systems like Ubuntu do not install all the development libraries and tools. So I proceeded to tear my hair out for over a day wading through endless package lists trying to find what I would need to get development headers and the various tools necessary to build software (the morning of the tutorial I discovered the laptop didn’t have any man pages. What the hell?)

Granted, such things are essentially trivialities, and I accept that they were the sort of thing that one runs into when working on a new system. No big deal. Sure I could easily have built a Gentoo system in less time, but it’s not my machine and in any case I was enjoying the learning experience.

Far more interesting was living on a new distro for a few weeks. It was nice to experience all this “polish” that I’ve heard people going on about, and I was indeed duly impressed. After a while, though, I started to notice all kinds of little changes that Canonical has made to the Desktop that are really cool, but which have not been contributed back upstream to GNOME. That bothers me a little bit, but I’m hopeful that in time this sort of practise will fade in favour of them working more closely with the upstream projects they are using.

Meanwhile I also got to trial a new laptop brand. I gotta say I was really impressed with the build quality, robustness, and power efficiency of the HP corporate laptop line. This one is a couple model-years old, but I was able to have a few good chats with Bdale Garbee about it and he walked me through their current line up. After this experience I can definitely say that we will be getting HP laptops in the future.

Drove me nuts having a different keyboard layout to deal with for a few weeks. And having just about spent enough time on it to get it in my fingers, now my laptop is repaired and I’m once again mistyping everything… :)

Again, thanks to Steve who totally saved the day. And thanks to everyone anywhere who ever contributed to all the wonderful software that made the transfer from one system to another miraculous — and easy.

What about next time?

So what I have I learned?

I travel a huge amount, and having my laptop blow up is clearly something I need to be more prepared for. Remote backups are still necessary, of course, and the SD card I carry around with more or less continues snapshots of my critical files is also clearly going to continue.

But it’s kinda obvious to me now that it would be a good idea to carry around an external USB enclosure with a hard drive big enough to back up my entire system — nice encrypted partition and all set, just rsync the whole damn thing. Disk space is cheap. Along with a boot partition holding a nice generic runs-everywhere kernel, that would be enough to not only recover from, but also boot from live the next time my computer fries.

AfC

Quite unsurprisingly they define increasing angles as going from the positive x axis on toward the positive y axis. Nothing unusual about that. The only thing that was surprising is that they even mention this in their documentation.

I should know better.

What I totally missed was the implication of this. I didn’t quite clue in that the positive y direction in screen positioning and page drawing is down, and so increasing angles go clockwise. Using cr.arc() to go from 0 to say π/3 radians does not give a rise of 60° like I expected; it gives this:

Whoa. This is not the counter-clockwise increasing θ like we’re all used to seeing in normal Cartesian or Polar co-ordinates. But it is indeed increasing toward the positive y axis. Oops. Oh well :)

So I made this illustration and added it to the documentation for Context’s arc() method. Really it’s mostly about pointing out which direction positive y is, but when I’ve learned something like this the hard way, I do my best to try and incorporate that knowledge into our public API. With any luck others can be spared my folly.

Drawn with Cairo, of course!

AfC

Update: Some people have pointed out that you can use a transformation matrix, and if you happen to (say) mirror across the horizontal axis then the clockwise notion would no longer apply. Fair enough; but if you have forgotten that +y starts out going down, then you’re not going to think to do such a flip in the first place.