This is in the gtk+ module, in the places-sidebar branch.

We have gtkbookmarksmanager.[ch], which are internal. This is just a monitor for ~/.gtk-bookmarks and some machinery to shuffle bookmarks. We may export that if there is need for it, but it's really simple right now - it's just a transplant from gtk_file_system_*_bookmarks() - now GtkFileSystem does not deal with bookmarks at all.

We have gtkplacessidebar.[ch], which is the problem that concerns us.

Outstanding issues in gtkplacessidebar.[ch]

Everything with 'nautilus' or 'Nautilus' in it has to be replaced. Calls to eel are already gone.

FIXMEs in the code

All the FIXME items in gtkplacessidebar.c are genuine (i.e. not leftovers from Nautilus) and need to be taken care of. All have comments saying what the problem is.


We have a bunch of "#if DO_NOT_COMPILE" - these are big chunks if-ed out so we can build the thing and test it while we finish the de-nautilus-ification.

Making bookmarks user-controlled

Right now the user can try to bookmark something, but various checks may prevent it from being bookmarked. We have to remove these checks. The idea is that the user will be able to bookmark any URI, he *can* have duplicates, bookmarks to nonexistent files (maybe they are on a removable volume), etc. Basically, all URIs are allowed; no checking.

The file chooser may need to filter out non-local bookmarks (or better, gray them out to preserve their positions in the list - see the next section).

Making the bookmarks API based on positions

Right now the GtkBookmarksManager API is a transplant of what we had in GtkFileSystem. It is awkward in that enumeration returns a GSList of GFile, but this doesn't get you the bookmark's label - you have to call a separate function.

Setting a bookmark's label works based on a GFile, not a position in the list; this assumes that bookmarks are unique. Since we will remove this restriction, we have to make this based on a position instead.

We have to turn the API from exposing a GSList, to just enumerating by positions. get_n_items(), get_item(nth), etc. Return a pair of (URI, label) rather than having separate functions for each field. Reordering should be atomic rather than remove/insert as it is right now.

Fetching icons for bookmarks

There is an outstanding call to nautilus_bookmark_get_icon() which has to be replaced. The current file chooser code loads bookmark icons asynchronously, but GtkPlacesSidebar is mostly synchronous and we need to allow for async "get file info" operations.

Drag and drop

There is some leftover machinery that uses Nautilus APIs for DnD.

In the file chooser, URIs dragged from the outside only create bookmarks. In Nautilus, these can cause file operations (move files to a bookmarked directory, for example). We need to allow this kind of custom behavior. One option is to have GTK+-like drag signals, but that expose bookmarked items instead of rows or pixel coordinates. Nautilus would just hook to these signals and handle them however it pleases.


There is some code that calls nautilus_trash_monitor. I don't know if GIO provides enough machinery to handle this on its own; if it does, the code should be replaced; otherwise, we may need extension points so Nautilus can add the trash bits to the places sidebar.

Volume mounting

There are some calls to nautilus.*mount - these need GIO-ification, maybe with some side signals like "a mount was started" so Nautilus can know what's going on.

Outstanding issues in gtkfilechooserdefault.c and gtkfilechooserprivate.h


There are chunks if-ed out with "#if REMOVE_FOR_PLACES_SIDEBAR". This code should go away when the conversion to using the places sidebar is finished.

Non-Nautilus, non-GTK+ clients

We should contact the XFCE people to see if the basic API in GtkPlacesSidebar is sufficient for them.

Projects/GTK+/GtkPlacesSidebar (last edited 2013-11-22 15:36:55 by WilliamJonMcCann)