Category Archives: General

Linz Connection problems

This is a terrible week for internet connectivity in Linz. For the last few weeks the company rented a room in the university building down the street so I could walk down there with my laptop and use their unproxied connection. But that isn't available anymore. I might start knocking on doors in the students' building and offer them euros for the use of their network sockets.

So this week will be an experiment showing how much I can achieve just by sending emails.

I found LinzNet who seem to offer a better, simpler, ADSL than Austrian Telekom. Has anyone used them?

This is the Hauptplatz in Linz. I like it, but I don't know why. My new apartment is nearby.

easy-fix

aldug has now added an easy-fix column to our GNOME bugzilla reports, showing bugs with the easy-fix keyword. In combination with the column showing the number of outstanding patches, I think this is the single best way to involve new people and to reinvolve existing people. But maintainers must use it.

gtkmm

Cedric Gustin finished the changes necessary to make gtkmm 2.2 build on Windows. Even better, he created a Windows installer for it, like the one for GTK+. Soon he should have a version that installs an example too. That should be very persuasive. People often list Qt's cross-platform ability as an important feature so I like to show that gtkmm can do it too.

libsigc++

Martin Schulze and Andreas Rottmann are doing great work on the unstable libsigc++ 2. We should have a first tarball release soon.

And Dr Dobbs magazine had a nice article recently about the 1.2 API, comparinng it favourably to C#'s equivalent.

ClearQuest

I started using ClearQuest yesterday and, surprise, surprise, it is a disaster, just like ClearCase. Eventually people must learn that software that's so expensive that only a few people use it is invitably awful. People get a certain confidence from paying vast amounts for proprietary software, but that confidence never lasts more than a few days after the installation. I keep seeing the same situation over and over again. The future can only be better.

The whole idea of a bug-tracker which only allows (some) developers to enter bugs is silly.

Bonobo(mm)

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.

D-BUS

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.

libxml++

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.

Linz

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.

ClearCase

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.

Clearcase

  • 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.

Going to Linz, Austria

I’ve been back in Munich for the weekend, but I’m about to leave again for Linz, Austria for another week of training – on a proprietary C++ GUI toolkit for mobile phones. It looks like I will continue to work in Linz afterwards, but it might yet be Frankfurt. Linz seems pleasant and it could be nice to be there during the summer.

I used the connection-less time to fix the memory management in mysqlcppapi, something that I’ve been meaning to do for the last year. I also updated Glom to use the latest version, and fixed a few more regressions left over from the port to gtkmm2. This also showed a libxml++ problem so I fixed that and released a new version.

Matthew Tuck provided some fixes for some remaining “Save Changes?” problems in Bakery caused by the GUI-abstraction change. It’s nice to see these fixes automatically available to all applications built on Bakery.

Nie wieder

Germans tend not to express their opinions much, but it’s great to see that as individuals they have a limit. “Nie wieder” is a powerful moral imperative. I’m really glad I live here.

GNOME release notes

gman, jfleck , louie, jdub and I spent a frenzied few days working on the GNOME release notes. Because we use the latest cvs stuff all the time, seeing gradual changes, and because people don’t use NEWS files like they should, it was really hard to find out what exactly had changed. But I think it turned out well. I was pleasantly surprised by jfleck‘s perfect Strunk & White-like rewriting/editing ability. He can write. That’s rare.

I’m glad that we got the “GNOME is simple and works” message across. It really is the most important thing about GNOME these days, and it’s a very good thing. I think it’s easy for people to consider deployment of a small, non-mysterious, comprehensive system.

I wasn’t around for the actual release because I had to travel up to Hannover at the last minute for an interview about a new contract. I seem to have bagged it, so I should be working in Frankfurt for a few months after 2 weeks of training in Linz, Austria. I’m particularly pleased that I passed an Interview in german. I had 2 disastrous interviews in german in the past and those are the only interviews in the last decade that I’ve not had offers from. I’m still a long way from fluency, but I’ve improved lots over the last few months. Reading is getting easier too – I’m reading newspapers almost as quickly as english ones. I’ve almost finished Thomas Brussig’s Helden Wie Wir, which is teaching me lots of dirty words.

Although it’s good that the maintainer of all of these projects can pay the rent in the future, I will probably have less time for the next few months. Luckily everything is clear and planned and people know what to do.

libxml++ was very frustrating recently. I had to explain to an over-eager contributor why his patch should not contain unrelated changes or introduce regressions, and we had to revise his patch 6 times. He was then given cvs write access and made a terrible mess of our cvs because he had not been given a chance to learn how to contribute. Rather than have to ask someone not to do the wrong things it’s normally much easier to just say “You can do this” and let them learn why by watching. It sounds unhelpful, but people only seem to understand maintainership when they see it done. Some day I might write some justification down in one document but I think first-time contributors still wouldn’t understand the importance without first-hand experience.

I have so many projects at the moment that it’s very frustrating to think again that I should take over another maintainership just to keep a project on track.

Glom port to gtkmm2

After a year or so of occasional porting while I waited for other stuff to compile, I finally finished porting Glom to gtkmm 2. This one has much simpler dependencies, with no need for Xerces-C++ or gnomemm or GtkExtra–. There is now a slim chance that I might actually start adding functionality to it, though I’d like to explore use of libgda instead of just using MySQL

glibmm and gtkmm 2.4 are in gnome’s cvs, with those module names, and pretty much ready for release as soon as glib and GTK+ 2.3.0 versions are released.

Now it’s just orbitcpp that still needs work.

gtkmm 2.2.0

We released gtkmm 2.2.0 and began branching for gtkmm 2.4 which will break API to allow us to make some more improvements. I’m very glad that gtkmm is now so much more in sync with GTK+ compared with the past.

And now that libxml++ has been released with its new DOM-like API, I was able to release the new UI-abstracted Bakery and a couple of apps that depend on it – PrefixSuffix and SubSubSub

I updated the orbitcpp web page, created a gnome.org mailing list, and released a new version to try to stimulate some more interest. I wish we could get people working on it so that gnomemm could stabilize. libgnomeui’s dependency on libbonoboui is starting to become annoying because it doesn’t seem to be used much in the API. And I’m starting to think that it was very foolish for GNOME to decide to write its own CORBA ORB and to expect language bindings to write their own CORBA mappings for that ORB. I thought the whole point of CORBA was reuse.

However, I’m not impressed by KDE’s DCOP alternative – strings are a lousy API. And they built that awkard system because of performance problems with their own CORBA ORB (something that isn’t a problem with ORBit), instead of just fixing the performance problems. There may be other reasons not to use CORBA (e.g. having to use CORBA types) but that’s not what was mentioned at the time.

For Bonobo to survive, I think it needs to slim down to only a component model and surrender the UI/menu/toolbar stuff to GTK+ and its new libegg APIs. If Bonobo becomes simple and tightly focused then maybe its API can be improved by the community.

Real life is kind of in limbo at the moment. I decided I have to give up this freelancing malarky and find a real job. Hopefully I can get something in Muenchen that’s at least Unixy. I find it very strange to be in this position after the last few years of success.

I run now in the scraggly Truderingerwald out here in the Munich suburbs. There are few things better than running at constant speed across a snow-covered field with Bernadette on the headphones, trailing breath behind me, thinking I would so buy the soundtrack to my life.

orbitcpp

I played around with orbitcpp a bit, understanding how it writes appropriate C++ code when it encounters IDL. I mostly implemented the CORBA::Any stuff, and I’m confident that I can finish that off now. I’m pleased it’s no longer a mystery. I do need to get more people involved, particularly that whole group of orbitcpp-0.3 people. Unfortunately we can’t expect orbitcpp to be API stable for a while, and that prevents libgnomeuimm from being stable too.

Therefore, I have almost finished converting Bakery to depend only on the stable gtkmm, gconfmm, and libglademm libraries. This means that the Bakery-using applications can actually be distributed because they won’t have unstable dependencies. Well, that’s assuming that I can push libxml++ towards a stable API.

I’m really pleased with the result of this refactoring in Bakery. I have mostly separated the whole App/Document/View model implementation from the GUI presentation of those concepts. This means it will be easy to create a Bakery_GnomeUI extension library which uses Gnome::App and libgnomeui menus and toolbars instead of the gtkmm stuff. I’m confident that we could even create a Bakery_Qt version (I did a proprietary standalone Qt port of Bakery once). You’d never reach this level of abstraction and reuse in C.

Bakery has been getting more attention recently, of the “Thanks, that’s made my life easier” kind.

API/ABI-frozen libglademm

I released an API/ABI-frozen libglademm, with some last minutes improvements from danielk. Hopefully this will encourage people to use it rather than writing all that tedious source code just to layout widgets. I added a chapter about it to the gtkmm book to encourage its use.

We also released gtkmm 2.1.1, a couple of days after GTK+ 2.2.0. Our next release can probably be 2.2.0 – I’m pleased that we are back in sync.

I spend the last couple of days fixing the Gtk::Clipboard API, writing examples to use it, and then writing a chapter in the book to explain it. It seems pretty good now, and naturally it’s much simpler than the C API.

While waiting for gtkmm to rebuild, I updated the Release Planning modules list on developer.gnome.org and made sure that meta-gnome-desktop in jhbuild includes the new GNOME 2.2 stuff such as GStreamer and nautilus-media. Apparently aldug and Wayne Schuller are working on the bugzilla GNOME report scripts. I’m looking forward to using them as the basis of a release status and how-to-help page.

libgnomecanvasmm and gconfmm: API frozen

I released 2.0.0 API/ABI-frozen versions of libgnomecanvasmm and gconfmm, and I expect to release 2.0.0 of libglademm soon. I should add a libglademm chapter to the gtkmm book, because it’s obviously the sane thing to use. Freezing these parts of gnomemm should make it more obvious that the remaining work needed is in libbonobo*mm and orbitcpp. I’m thinking of spending the holidays fixing the “WRITE ME” parts of orbitcpp, though there will be quite a steep learning curve because I haven’t paid enough attention to what cactus has done.

Using the new XML-capable Bakery and libglademm, I was able to write a new application – SubSubSub. It’s something that I’ve tried without much success in the past with PowerPlant and MFC/ActiveX, but I was able to do it with Bakery in only a couple of days. Unlike MFC’s resource files, libglademm makes it really easy to visually edit the appearance of custom widgets and that really helped.

However, I did have to fix a few libxml++ bugs, and the released libxml++ still needs fixing. It is gradually moving towards a more DOM-specification-compliant API, with various node-type sub classes, though we’ll try to keep things simple.

I’m really impressed by jamesh‘s new “dot” feature in jhbuild, which shows dependency graphs with graphviz. Here are some gtkmm examples, and one for the GNOME 2.2 Desktop, and one for all of the stuff in jhbuild. Note that these are cvs-build-time dependencies – it’s slightly simpler for tarball/binary dependencies

GNOME 2.2 seems to be trundling towards it’s release date fairly well, with only minor problems here and there. The exciting visible changes stage is now over, so it’ll be mostly just stability bugfixing from now on.

I made a bit of a fuss about the GNOME HIG and nullity‘s recent neglect of it. This resulted in some clarification, particularly the removal of some silly problem-causing technical advice, and a clearer understanding that GTK+ won’t do anything much about the HIG until after GKT+ 2.2.

I’ve been skiing a couple of times recently – to the Stubai glacier and to Gerlos in Zillertal – pretty good conditions, particularly at Stubai. Skiing is so exhillerating – it’s like having super powers.

I saw the Copenhagen play, in german at the TeamTheater. I loved how it played with quantum theory ideas to flesh out an episode about which we know very little of substance.

Still no contract/work.