TWITTER UPDATES

Since John is about ready to release D-Bus 1.0 I thought I'd finally fix up all the warnings from Doxygen. The API reference docs were mostly complete already, but I found a surprising number of inaccuracies (some things were wildly wrong or misleading, since the library has evolved so much since they were written). I also added a lot of recommendations, extra detail, and reworded stuff for consistency and clarity. Hopefully future API users will be much better off.

Check out the results, and please send improvements.

I noticed that Doxygen is generating man pages for the whole D-Bus API, though nobody is installing them in packages right now. Sometimes "man dbus_connection_open" can be nicer than searching the web.

Jeroen Vermeulen wrote a nice intro to D-Bus worth checking out also.

My sincere hope is that libdbus is basically done, and that most feature requests will be rejected after 1.0. The higher-level bindings, on the other hand, can still use a lot of work. The tutorial (as opposed to reference) docs and the spec need help. And the test suite can always be stronger, it's suffered since gcov kept changing its format and my "make coverage-report" feature bit-rotted.

Andrew Cowie blogs about dynamically building Java-GNOME by messing with bytecode. These bytecode-munging libraries are fascinating in a "wow, that's pretty cool" way. (valgrind does the same thing, but with machine code instead of bytecode - valgrind is also fun to play with.)

When I looked at some of these libs, I thought ASM looked good - small, fast, and easy to use. It has a feature where you can write your Java class, then convert it to an ASM code generator, then modify that generator. (Or write your "before" and "after" Java class, convert both to ASM, and compare.)

I'm not sure there's a lot java-gnome could do with bytecode that it couldn't do with full GLib introspection and proxies, though.

btw, someone please hack on full introspection for GLib... that would nicely shrink a lot of language and IPC bindings.

My wishlist for GLib introspection is that a single, simple, smart command generate the typelib, the glib-mkenums stuff, and the glib-genmarshal stuff. glib-mkenums and glib-genmarshal require you to write all kinds of gunge in your Makefile that would be more nicely done in a real programming language instead of inline shell cut-and-pasted into every Makefile. And I wouldn't look forward to adding a third block of Makefile gunge to get the typelib. How about just generating a public/installed header file, a private header file, and a .c file from a single smart command and single input file - that would be sweet.

People keep acting like it's nuts to use Subversion instead of git (or one of the other long list of distributed alternatives), and I feel like I'm just missing something or getting too old to understand the kids today.

I found an old series of blog posts about how the different models support different community dynamics, Greg Hudson, Ian Bicking, Bryan O'Sullivan.

I think what I don't get yet is why you'd want to maintain a bunch of local changesets for very long. The Linux-kernel-style fork-fest seems just nuts for anything I'm working on. Usually there are less than 10 people, often less than 5, that are really doing much work, and any other contributors are sending a one-liner every few months. There's just no problem that I see here that distributed version control would solve.

Maybe it's a personal style issue. On all my projects I almost compulsively commit to the central repo every day - too afraid of losing work when a hard drive goes south or something. I know other people who delay committing for months at a time which I would find nerve-wracking. I also press save every 3 minutes whenever I'm editing a document.

The obvious reply is that most people don't have commit access. But if someone's doing any kind of significant work, I think they should. And for my projects I've essentially always given out access as soon as someone did any kind of largish patch or frequency of patches. Again, a typical number of people doing work would be 3, 5, maybe 10 - 10 is a pretty large project by most open source project standards.

Aside from community dynamic / "what is the point of decentralization" two other things bug me:

• There are so many choices (cvs, svn, git, mercurial, darcs, bazaar, arch, monotone, etc.). It used to be that if you understood CVS you could quickly work on any project. These days, if you want to work on a project you might have a few days of ramping up on the quirks of their SCM before you can do anything. And they are all quirky. And I just don't care about SCM that much and don't want to think about learning new ones.
• The distributed systems seem pretty wild from a user experience standpoint. In the sense of "jeez, I can tell a (kernel, Haskell, shell) programmer wrote this." Subversion may be less flexible but it's also less confusing. Call me stupid.

Also, I used to walk to school both ways uphill in the snow, fyi.

For the version of Mugshot we're going to release shortly, we redid the UI (it looks something like this). Amazingly, there's no good cross-platform way to implement a custom UI along these lines. The old version of Mugshot uses an embedded IE control on Windows and a custom GTK+ widget on Linux.

The solution we're trying is a quickly-hacked-up custom canvas. (See gtk-devel post, current subversion location.)

It turns out that One Laptop Per Child has similar requirements, see for example these mockups (there are also newer mockups but I can't find a link to them). We broke HippoCanvas out of the Mugshot sources so the Sugar project could try using it and see if it works for them also.

A couple years ago, throwing a canvas together in a few days like this would have been way too much work; the reason it's plausible today is that Cairo and Pango handle so many of the hard parts.

HippoCanvas has some nice improvements over GtkWidget. The best one: modernizing the layout system. It's not too often one notices GTK's breakage here, but sometimes it's very visible. The two big changes in HippoCanvas layout are to add height-for-width and to distinguish between "minimum size" and "natural size." (GTK's "size request" defines a minimum size for a widget).

The natural size feature makes ellipsized text work properly, something that's essentially impossible in GTK+ (without writing a custom canvas widget anyway). Here's a real-world example problem we had before implementing natural size - implementing this with three GtkLabel widgets would have this same bug:

In the first shot, one of the text items is ellipsized while the other gets extra space. In the second, both get extra space even though in a real app you'd probably want all the extra space to be on the right side of the window (left-aligning the text).

The problem is that GTK+ only supports a minimum size. To allow text to ellipsize, you have to set the minimum size to zero (or something small). However, this means you have to pack the text item in a box such that it expands when there's extra space... and that means GTK+ will add bogus whitespace as in the above screenshots. If you don't pack the item such that it expands, it will just always be the minimum size (i.e. zero).

HippoCanvas allows items to have a minimum size and a natural size. The algorithm is that if the layout box gets more than the minimum size, first it brings all items up to their natural size (whether they are "expandable" or not), and then it distributes whitespace among expandable items.

So for example, here's a test layout at its natural size:

And its minimum size:

And two points in between:

The algorithm brings smaller items up to natural size first, so the yellow item on the right is fully visible while the two longer items are still ellipsized. If you think about an example like the "Blah blah blah blah - Havoc" images earlier, the idea is to display all of "Havoc" first, and then as much of "Blah blah blah blah" as possible.

Expandable items only matter once everything has its natural size, like this:

One way to understand the problem with GTK is that it doesn't support the "expand=0 ellipsize=1" behavior illustrated in these screenshots.

A downside of a more-complex layout system like this is that layout containers are tougher to implement. However, this is the wrong thing to optimize for, because virtually nobody implements layout containers. GTK+ doesn't have very many but still has too many of them; we consolidated GtkFixed, GtkHBox, GtkVBox, and GtkAlignment/GtkMisc into a single box item, and made all canvas items have xalign/yalign properties. This already covers 98% of layout needs.

In the end, this kind of corner case probably doesn't matter very much; after all, HTML, Flash, Windows, GTK+, etc. are all very successful despite missing/flawed solutions for layout. But it's nice to get things right in this new code.