15 December 2004
Mataró
The conference has been great so far. The PyGTK BoF on the weekend was very productive, and I got to meet Anthony Baxter (who as well as being the Python release manager, wrote a cool VoiP application called Shtoom). There was an announcement of some of the other things Canonical have been working on, which has been reported on in LWN (currently subscriber only) among other places.
Over the weekend, I had a little time to do some tourist-type things in Barcelona. I went to La Sagrada Família. It was a great place to visit, and there was an amazing level of detail in the architecture. You can walk almost to the very top of the cathedral, and see out over the Barcelona skyline (and see various bits of the cathedral not visible from the ground). I’ll have to put my photos up online.
I’ve been using using Bazaar a bit more at work, and it is becoming quite usable, compared to tla. It is a little interesting using daily builds of baz from the 1.1 development branch, where some features appear, get renamed or removed as they get developped, but it has a few more useful features not found in the 1.0 release. From a user point of view, it feels like the command line interface for baz is being designed to be easy to use, while tla‘s feels like they made choices based on what was easy to implement.
I built some Fedora Core 2 i386 builds of the 1.0.1 release, and some 1.1 snapshots that are now up on the Bazaar website in case anyone wants to try them. When I get back home and install FC3 onto my AMD64 box (it only has Ubuntu on at the moment), I’ll do some FC3 x86-64 and i386 builds too.
8 December 2004
Mataró
I’ve been in Mataró (about an hour from Barcelona) now since Sunday, and it’s quite a nice place. It is a bit cooler than Perth due to it being the middle of Winter here, but the way most of the locals are rugged up you’d think it was a lot colder. It’s great to catch up with everyone, and a number of pygtk developers will be turning up over the next few days for the BOF on the weekend.
Gnome Foundation Elections
Congratulations to the new board members. It is a little disappointing that only about 56% of members voted though. Once the membership committee has the anonymous voting stuff set up, it might be worth doing the preferential voting referrendum.
jhbuild
I’ve been working on some preliminary documentation for JHBuild, which is available here. It should be useful for new users and people looking at writing new module sets for it. It has a fairly complete command reference and config file reference, so it is probably useful for current users too. It would be good to add some information about setting up a tinderbox like the one Luis set up for Gnome.
Nautilus Extensions
One of the changes in the Gnome 2.9 development series is the removal of most of the Bonobo code from Nautilus, which results in a speed boost due to lower complexity and less IPC overhead. This had the effect of breaking existing bonobo based context menus, property pages and views. The first two can be converted to the Nautilus extension interface, but the second has no equivalent in the new code (partly because Nautilus is concentrating on being a file manager these days rather than a universal component shell like it was in the early days).
Two of the casualties of the change were gnome-control-center‘s font and theme code, and nautilus-media. Since I wrote the font browser code in gnome-control-center, I updated it to work again. It isn’t clear whether nautilus-media will be updated, since the view was a major component of it, and most of the remaining functionality is provided by totem.
Context Menus
If you are looking at updating a Nautilus context menu to use the new extension interface, fontilus-context-menu.c is a pretty good example to model your code on.
One of the big differences is the way Nautilus extensions are loaded compared to the old context menu API. With the old API, you would provide a Bonobo component and set a number of properties in the bonobo-activation server file listing a menu label, the list of mime types the context menu applies to, what URI schemes it supports and whether it supports multiple files. Nautilus could then do a single bonobo-activation query to find out what context menu items correspond to the current selection, and add them to the menu. If the user selected one of the items, the corresponding component would be activated, and an event sent to its Bonobo::EventListener interface.
In contrast, Nautilus extensions are initialised on Nautilus startup. They indicate that they provide context menu items by implementing the NautilusMenuProvider interface. When the user brings up the context menu, the get_file_items method will be called on all extensions that implement that interface. A list of NautilusFileInfo objects is passed in, and the method returns a list of NautilusMenuItem objects. Also, Nautilus extensions are run in-process while Bonobo components could be written for in-process or out of process use.
One of the benefits of this system is the added control of when to display a menu item, and what to use as the label. If you want to only display your context menu item when 42 text/html files and one image/png file are selected you can. However it does mean that each new extension causes some code to be run before popping up a context menu. I have no idea how this compares time wise to the time taken for the previous bonobo-activation query though.
Property Pages
The interface for property pages is quite similar to the context menu interface. As with context menus, you have an imperative NautilusPropertyPageProvider::get_pages interface rather than a declaritive interface based on activation properties. This has the benefit that you can simply not provide the page when the properties in question are not available for the file (with the old setup, you’d end up providing a properties page stating that there is nothing to display).
The other interesting parts of the extension interface is the NautilusInfoProvider interface that lets you attach extra information to files, such as extra emblems or custom attributes, and NautilusColumnProvider, which lets you provide additional columns for the list view that map to custom file attributes. One example of this is nautilus-vcs, which can show revision numbers for files in CVS working copies and adds emblems indicating the file state.
Of course, there are downsides to the extension interface too — since extensions are always in process, they can crash Nautilus or leak memory. However, it was already possible for Bonobo based extensions to do this if they were designed as in-process components and badly written …
Another issue is that language bindings might find it more difficult to support the extension interface where the language runtime would have to cooperate with Nautilus, compared to out of process Bonobo components where they have more control. I guess we’ll see what happens.
1 November 2004
Libtool
When looking into the libtool problem I mentioned earlier, I decided to take a look at the libtool-2.0 betas. Overall, it looks pretty good. I’ve updated the gnome-common autogen.sh script to support it. So if a package uses the LT_INIT macro, it will call libtoolize for you.
One of the new features in these versions of libtool is that if you have a AC_CONFIG_MACRO_DIR(directory) call in your configure.ac file, it will copy the libtool M4 macros to that directory. If you then call aclocal with the correct -I flag, autoconf will use that version of the macro.
This means that you will get consistent versions of ltmain.sh and libtool.m4, which is a lot more reliable. With the old setup, the version of ltmain.sh you got would depend on $PATH while the version of libtool.m4 would depend on the aclocal search path. With the new setup, it just depends on $PATH.
The only problem is that aclocal doesn’t automatically check the macro dir for macros. This is pretty easy to work around. Just pass the appropriate -I flag to aclocal in autogen.sh, and make sure ACLOCAL_AMFLAGS gets set appropriately in your Makefile.am‘s. This second part can be done from the configure.in file like so:
AC_CONFIG_MACRO_DIR([m4])
...
# make sure $ACLOCAL_FLAGS are used during a rebuild.
AC_SUBST([ACLOCAL_AMFLAGS], ["-I $ac_macro_dir \${ACLOCAL_FLAGS}"])
(the above will also pass $ACLOCAL_FLAGS to aclocal on a rebuild, which is expected when building most Gnome packages).
I also updated the gnome-common autogen.sh script to check for AC_CONFIG_MACRO_DIR, and call aclocal correctly, so a package maintainer doesn’t need to do anything special.
This system could benefit some of the other Gnome related build tools like intltool and gtk-doc — I recently got CC’d on an intltool bug that seemed to be caused by mismatched macros and support files, so people are tripping over the problem. It should be pretty trivial to modify intltoolize to check for AC_CONFIG_MACRO_DIR, and copy over the macro file if it finds it. This wouldn’t affect its behaviour on existing packages, but would be more reliable on packages that have been updated to use the macro.
I did some initial Fedora Core 2 packages for Bazaar (a new GNU Arch command line tool sponsored by Canonical). It is only an i386 build, but I’ll add an x86-64 build once I have FC2 or FC3 set up on my desktop (so far I’ve only got round to installing Ubuntu/AMD64 on it).
At the moment baz is quite similar to tla, but there are some promising interface ideas that should make it a lot nicer to use. If you’ve avoided Arch due to tla‘s complexity, baz might be worth trying when it develops further.
- 1
- 2
- 3
- 4
- …
- 8
- Go to the next page