Recent discussions about D-BUS and Bonobo (not necessarily versus) got me thinking about bonobomm again.

I think the main reason bonobomm hasn't moved very fast is that nobody really seems to need to use it, so there is nothing to drive its development. I was thinking why I have found COM and ActiveX so useful (though difficult) on Windows in the past, but don't feel much need for it on linux. I think these are the reasons:

  • Unlike GTK+ and Qt, MFC and VB don't do widget/control nesting, so it's very hard to define new native widgets that are groups of other widgets.
  • MFC and VB don't provide decent high-level controls such as grids or trees, so everyone implements their own. They do it in COM because of 1. Instead, GTK+ provides widgets that are actually usable.
  • Lots of companies use both C++ and VB so it's nice to reuse code in both. Most linux application still seem to be written in C or C++ so apps can reuse code without a binary interoperable component system. I think the growth of Python as an application development language could change that, but it isn't happening very fast.


I don't like the idea of D-BUS string APIs, but I can live with it for very simple response/request stuff. I think a CORBA-based system could be a lot neater, but it's very clear that ORBit/Bonobo has had its chance and it's time to use something that will get the job done. It's not a failure of CORBA – it's a failure to document and explain before pushing on with ever more development.

Therefore Bonobo's best hope for survival is to stop attempting to be everything and concentrate on being viable for a much smaller amount of functionality. That means dynamically-chosen cross-programming-language (visual) components and probably nothing else. It is yet to be seen whether that's actually useful or necessary for anything other than graphs inside spreadsheets.


We took a vote to resolve the everything-should-be-a-template versus the just-use-ustring argument which didn't solve the issue but at least made it easier for me to say “you fork if you want to”.

libxml++ 1.0.0 should bre released quite soon, with a frozen API, so take a look now before it's too late.


I'm gradually settling down in Linz, getting back to Munich for the weekends as much as possible. I am still suffering terrible internet withdrawal, grabbing moments of un-proxied cvs access here and there. This weekend I found a
wonderful little apartment for a few months, so I guess I'll have to get some DSL sorted out. Unfortunately I can't move in for another 3 weeks.

I didn't like the idea of working outside of Munich, but Linz is actually quite close – only 3 hours on the train. Plus it should be quite cheap to live here. And I'm really looking forward to weekends in the mountains in the summer.

After I arrived, I was disgusted to see that the Austrian government teamed up with the far-right party again. I was even more disgusted to see that it was hardly reported in foreign newspapers or TV. Looking for appartments here showed that there really is a problem with the far-right – many of the ads specify clearly that they will only consider Austrians, not even Germans. Not only is that illegal under european law, but it amazes me that this society finds it acceptable.

Paid work is quite frustrating at the moment. I'm dealing with an eccentric build system and an eccentric version control system. I think ClearCase is to blame for most of the problems.


Quite apart from the difficult of using it, Clearcase actually seems to be lacking major functionality. It is quite hopeless compared to regular cvs combined with an lxr/bonsai web site. Apparently it deals well with branches, but so far it looks like it just requires people to branch more often, as workarounds for trivial ClearCase problems. Branching is always complex and should be restricted to maintenance/development branches and occasional short-term experiment branches. The difficulties of not-branching are generally less than the difficulties of managing branches.


  • doesn't allow you to review your changes before checking them in, so all kinds of crap ends up in the official sources.
  • doesn't show you changes per-directory, only per-file.
  • doesn't, or doesn't easily, show you the check-in comments when it shows you changes to a file.
  • doesn't, or doesn't easily, show you the changes when you review the history of a file.
  • doesn't, or doesn't easily, show you changes made in the same check-in when it shows you changes to a file.
  • encourages the use of complex config scripts to define views instead of just offering to show particular branches. So in addition to multiple branches, teams finding themselves using multiple complex combinations of those branches.