Like Eating Glass

Desktop-devel-list (d-d-l) is an interesting place. You follow discussions that usually tend to fork off, moving through tangential arguments; but, in the end, some stuff keeps turning up. Lately, for instance, every thread seems to end up on discussing about Tracker.

Let’s take the discussion about having a GNOME “media center version”; you could think that such a discussion will end up laying out some ideas about a media center. Wrong: we ended up discussing about special folders – an argument that has already been discussed to the death. Obviously, if you read d-d-l all day you can’t really expect having time to actually work on the features (or the crack) proposed on the list. So, for a change, I decided to do stuff after saying what could be done. I decided to take an idea that has been floating around for ages and implement it.

This is a simple FileChooserDialog, but the places list have been generated using a bookmark file (read using GBookmarkFile) in $HOME/.local/share/places/gtk-bookmarks.xbel instead of $HOME/.gtk-bookmarks:

FileChooser using bookmark file
It’s completely identical to the FileChooser in trunk, really, but the places on the left are parsed using this.

The code, obviously, merges the places saved using the old format.

This, instead, is a trivial Perl application that can read all the places; it can also edit them, add new places and remove old ones:

GTK+ shortcuts editor

The fun part about switching the file chooser to the bookmark files is that it’s public API, so everyone can read, change and write these locations. We can add new locations to an application like we add Glade files, and let the file chooser populate itself by loading a file; so, instead of using:

  gtk_file_chooser_add_shortcut_folder (file_chooser, some_location);

we could use:

  gtk_file_chooser_add_shortcuts (file_chooser, PKGDATADIR "/shortcuts.xbel");

But wait, the keen reader familiar with the issue will interrupt, the whole point of this mess is localising the name the user sees in the interface. Indeed, that’s why the bookmarks have a title and a description; through intltool we can extract those two and put them into the po file for the translators to work on – exactly like we do for the Glade files. Before displaying the bookmark will pass the string through gettext, which will return the localised alias using the application’s domain – or we could add domain argument to the gtk_file_chooser_add_shortcuts() function above.

The file chooser can also load shortcuts automatically, using the application name to filter out what’s interesting.

Is this the most correct solution for this problem? I don’t really know, even though using bookmarks and applications make more sense than using dot-desktop files and MIME types (come on? MIME types? Like I should bind a directory to specific types of content and not to the applications that are most likely to use them – and what are “MIME types” anyway?). At least, however, this is a start and there’s some code to comment on.

The patches are roughly done, but the real treat would be to split the places section of the file chooser widget into its own widget and let other applications, like nautilus, use it directly without having to cut and past tons of code out of GTK+.

This entry was posted in C, developer, GNOME, gtk, open-source. Bookmark the permalink.

7 Responses to Like Eating Glass

  1. Nice!

    I didn’t understand this but would it be possible for programs to load Custom Bookmarks for just their program?

    And my other question, what theme/engine are you running?

  2. Alexander Larsson says:

    For another approach for directory translation that i’m working on:
    http://lists.freedesktop.org/archives/xdg/2007-February/009343.html

  3. ebassi says:

    @alexl:

    yeah, I’ve seen your proposal, and I mean to comment on it as soon as I can. in short, though: I prefer having real folders with bookmarks interpreted by the applications, a way for ISV to add new bookmarks and a way for the users to change those bookmarks instead of changing the folders.

    @mårten:

    the idea would exactly be that every application installs a set of bookmarks into a specific place (XDG_DATA_DIRS/places) and the FileChooser picks those places up depending on the application name (or another series of filters we can add); this last bit still needs to be fixed, but I expect to have it ready before FOSDEM. :-) as for the theme I’m using: marble-look for GTK+ and tactile for metacity.

  4. Luis Villa says:

    People actually writing code! (both you and alexl.) Will wonders never cease? :)

  5. liberforce says:

    That seems really nice. I also agree that shortcuts sensitive to some applications (or application kind ?) would be great. Mainly, eog would have only shortcuts to my image directories.

    But how do you handle the case of a person adding for the first time some places? Suppose there’s one single place where he puts all his stuff (wich may become more and more frequent with tools like beagle). For each app he uses, he will have to add that specific directory. So we may also need user-defined places shared across applications. Does your sample handles this ?

  6. So a general Bookmarks (as it works now) is read for every applicaton and then you just add the specifics for it.

    What would be really cool is if I tagged/labeled one of my folders with nautilus as a Music folder it would then show up as a bookmark in all my music applications, If I tag it as Pictures it shows up in those apps.

  7. and with tagged/labeled I mean emblems…

Comments are closed.