I’ve been put (temporary) on the OLPC project at work, working on the update system for that. That, plus the fact that all my spare time (and then some!) are being sucked up by the baby means I have very little time to work on Gnome at the moment.
This means most of my work on gvfs is frozen atm, and I don’t have time to follow the gnome-vfs and nautilus lists much. This is just a temporary thing though, and in a month or two i’ll be back hacking on gvfs!
The (so far unnamed, but we’re working on that) baby hasn’t given us much sleep recently. But she is very cute!
I put up some photos on flickr.
For a long time Gnome and other desktops have been using an english directory name for the desktop folder (and a few other common directories like music, download and documents). There has been a lot of discussions (read: flamewars) on how to localize these filename. After the last one I’ve finally broken down and done something about this. So, I present to you xdg-user-dirs.
It is a desktop-agnostic (and dependency free) program that is meant to be integrated by distros so that it gets run very early in the login phase. It will then look at the users locale and system-specific default configurations and use these to create a set of folders in the users homedirectory. It also generates (or updates) a user configuration files that points to these directories so that applications can find them.
I’ve also created the gnome-specific module xdg-user-dirs-gtk and a set of gnome patches that integrates these directories into the Gnome desktop. With these in place (availible in the Fedora 7 rawhide repositories now) users automatically get localized folders like Music, Movies, and Documents, plus default bookmarks to these in the gtk file selector. Any changes to these folders (e.g. moves or renames) with nautilus will automatically be updated in the bookmarks and the user directory configuration.
The Gnome integration even detects when you log in with a new locale and asks you if you want to move your directories to the new language.
Its also very easy for the sysadmin to change the default directories created for users (or to disable the whole thing). Just edit a simple config file.
I’ve been looking at some nasty nautilus crashers this week, including bug 343488 which has several hundreds of duplicates in bugzilla. Thankfully the bug team has managed to mark all of these as duplicates, or this would be a major undertaking.
One problem with autogenerated bugreports like this is the lack of information in them. All they have is a backtrace (generally without debug information, i.e. pretty useless) and a short line of text saying what the reporter did at the time. You can get a better feeling for the bug by reading a lot of the duplicates and try to detect common patterns, but this only works sometimes.
Thanks to the miracle of separate debug info and debuginfo packages (which I created back in 2002) its now pretty easy to have a user create a backtrace with debug information. This makes the backtraces much more useful, and we eventually got someone to report a nice backtrace for the bug.
Sometimes that is not really enought, like in the case of this hard to reproduce bug. To verify my suspicions I really needed to see the stderr output from nautilus to verify that an assertion warning triggered. But the output from nautilus isn’t normally visible as nautilus isn’t started from a terminal. We eventually managed to find someone who could reproduce this and send us the end of ~/.xsession-errors which had the suspected output.
This got me thinking a bit. If that information had been availible in the automatic bug reports it would have been much easier to find this bug, and similarly with all crashes that spew several warnings or asserts before crashing. So, I wrote a patch for bug-buddy to output some extra information when it creates crash dumps.
The patch also adds some information on the kernel used, the X server used, whether accessibility is enabled and the selinux mode. I hope we’ll get this out to users soon so that we can do a better job fixing bugs.
I’ve spent most of yesterday and today in the ninth circle of X hell, also known as XKB onfiguration. However, I’m now starting to see the light from above.
Why would anyone willingly look at XKB configuration you might ask. Well, I recently got a MacBook Pro, and the keyboard layout it used is slightly different than the regular pc105 keyboard. The main problems are that the key to the left of “1” and the key to the left of “z” somehow got their keycodes swapped, and the fact that there is no right Alt which means its hard to type certain symbols (there is a right Apple key though).
There are various places on the internet that shows you the magic xmodmap incantations you need to “fix” this, but I wanted a real fix that would let anyone set up a MacBook keyboard. So, I set out to add XKB configuration that lets you use the gnome control center to pick the right keyboard.
So, I proudly present the result of my labor:
I added not only fixes for the keycodes, I also added the correct symbol for the eject button, a geometry description, and an option to make the apple keys act as Alt (since they are in the normal Alt positions).
There seems to be some redraw bug in the applet, because the return key isn’t rendered right.
I’ve already build the patch in Fedora Core (development), and the upstreams patch is availible here.
After some discussion with Michael Meeks about yesterdays post we decided to move the problematic gnome-vfs functions to libbonobo, so that we can totally avoid bonobo in gnome-vfs. This is ok, since these functions are useless unless you use bonobo yourself, so you’ll be linking to libbonobo if you use them. In fact all old apps are guaranteed to do this since gnome-vfs pulled in libbonobo.
So, what happens is that the function declarations are in the gnome-vfs headers, but the actual implementation is in libbonobo. This means we can now push gnome-vfs much lower in the gnome build stack. It now only depends on glib, dbus, gconf and libxml.
There is only one minor issue. Since we don’t want gnome-vfs to depend on bonobo I had to remove a bonobo include from the gnome-vfs headers. Its likely that apps that use these functions already include this header, but if they don’t they can just add that include, or define GNOME_VFS_INCLUDE_BONOBO to make gnome-vfs include it. The only application in Gnome that uses these functions is evolution, and it didn’t need any modification to keep building.
Earlier today I landed the dbus-vfs branch to gnome-vfs HEAD, which uses dbus for all communications with the gnome-vfs daemon. Also, gicmo moved the gnome-vfs monikers into a separate module, so we’re ready to remove bonobo from gnome-vfs now. Unfortuntately the gnome-vfs API has these calls in the public API:
Bonobo_ServerInfo * gnome_vfs_mime_get_default_component (const char *mime_type);
GList * gnome_vfs_mime_get_all_components (const char *mime_type);
This is unfortunate for two reasons. First of all it calls bonobo, so we have to link to and initialize the bonobo libaries, even if most gnome-vfs applications never ever call these functions (only evolution currently uses it). Secondly, the dependency on bonobo at buildtime puts gnome-vfs at a higher level in the build chain than we would like.
To solve the first problem I added some code to (optionally at build time) lazily dlopen and initialize bonobo only when needed. This means applications don’t have to link to bonobo when they don’t use it, but bonobo is still required at build time. (Check for the “Bonobo support method” output from configure.) Its slightly better, but ideally we would just not depend on bonobo at all.
I wonder if it would be possible to move these functions into libbonobo instead (they don’t really call any other gnome-vfs functions, not do they use types or data provided by gnome-vfs). That way we could totally avoid these problems.
Kris requested that I put up the presentation from the Gtk+ printing talk, so here it is.
Guadec is great this year, I really like the extended length of it. However, I seem to have gotten some kind of cold. I got a headache and don’t feel very well.
Today we finally landed the printing branch of gtk+. This means that if you build gtk+ from cvs (what will become 2.10) you get support for page setup and print dialogs.
The actual printing is done through Cairo, which recently has gotten some kick-ass work from Carl Worth on the PDF and postscript backends. On windows cairo draws using GDI, so the native print drivers are used. In fact, on windows you even get the native print dialogs.
From a users perspective there are two new dialogs. First the Page Setup dialog:
This dialog lets you set up the page size, layout and the printer margins. This is enough to let the application lay out pages, and is typically used very early when writing a document.
Then there is the actual print dialog:
You use this when you want to actually print the document. It lets you print to a printer or to a file. It also allows you to set all sorts of settings that control how the print job is handled. Some are generic, like what pages to print, and some are printer-specific like duplex or paper stapling.
This code is now mostly working, but we really need people to test it. So, anyone working on an application that prints, please port your app to this API and give us feedback on it. Its important that we get API feedback early so we can fix it early.
Today I took the memory use analysis from
and started fixing the things I noticed.
First I changed the text embedded in icons so that we only read 10×5
characters normally, and re-read more only when icons are larger than
“normal”. Then I changed the PangoLayout handling in the icon
container so that PangoLayouts are cached only for icons that are
visible in the view.
I also made the icon cache a bit more aggressive in getting rid of old
old cached icons. We now free most of the cache when Nautilus has been
idle for some time. We didn’t use to do this, which means that the
cache could use quite some memory if the last thing you did was visit
a directory with lots of thumbnailed files.
With the testcase of just starting Nautilus, displaying my homedir in
a spatial icon-view window we had this before:
[alex@greebo tests]$ ./analyze-memdump -s nautilus_before.dat
total size: 4848501
unknown type: 1536818
list headers: 137776
pixbuf data: 1292756
And, after applying the patches:
[alex@greebo tests]$ ./analyze-memdump -s nautilus_after.dat
total size: 3787194
unknown type: 1019389
list headers: 119936
pixbuf data: 1292756
So, for this usecase we saved about one megabyte of heap. Not
bad. Furthermore, when you close the window most of the pixbuf data will be freed after a while.
All of this is commited to CVS, please test it out and report any
If you are interested in the current memory use status you can look at the
data file generated after applying all the patches. (Use the