Author: James Henstridge

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…

Drive Mount Applet The new drive mount applet is now checked into the HEAD branch of gnome-applets, so will be in Gnome 2.10. There are a few things left to do, such as making it possible to open the file manager as well as unmounting/ejecting it. I did up a screenshot showing what it looks like as an applet. Libtool Finally managed to reproduce a particular libtool bug that people have reported on and off. It does show why some people decide that .la files are evil, since it doesn't occur when people delete those files ... A reduced test case can be found here. The problem occurs when you have multiple copies of a library in your linker library search path with associated .la files. In the test case, there are the following libraries: libfoo.so and libfoo.la in the directory /A. This is the library we want to link to. libfoo.so and libfoo.la in the directory /B. We don't want to link to this one, because it is old. libbar.so and libbar.la in the directory /B. Let's say I then try to link an app that needs libbar and the new version of libfoo, and happen to use the following link line: libtool --mode=link gcc -o main main.c -lbar -L/A -L/B -lfoo In the absense of libtool, this would result in us linking against /B/libbar.so and /A/libfoo.so (since /A comes before /B in the search path). However, libtool ends up doing something quite different. When it sees -lbar, it notices that there is a libbar.la in /B, expands that argument to the full path name of the actual library (/B/libbar.so), and prepends /B to the library search path. This means that when it gets round to processing -lfoo, it finds /B/libfoo.la instead of /A/libfoo.la, and links to the wrong library. If this sounds like an obscure bug, note that it also happens if we replace /B with /usr/lib. In this case, we don't even need the -L/usr/lib argument. So the following command results in linking with /usr/lib/libfoo.so instead of /A/libfoo.so: libtool --mode=link gcc -o main main.c -lbar -L/A -lfoo This sort of situation is quite common when trying to build some software into a separate prefix that is also provided by the OS, when you are relying on a few libraries installed in /usr/lib with .la files. After putting together the test case I tested it out in the latest development release (1.9f), and it appears that the problem has been fixed. Given that the libtool developers are so close to a 2.0 release, I don't know whether they would bother putting out another 1.5.x release to fix the problem. So if you do run into the problem, some possible solutions are: Upgrade to libtool-1.9f. I'm not sure how good an idea this is if you are producing tarballs, since they will be packaged with the development release too. Remove all the .la files in /usr/lib. Some distributors seem to take this route (eg. Ximian/Novell and Red Hat).