Why can't Nautilus just read ~/.gtk-bookmarks?

nat, the panel already does this, and it was agreed that its the bad thing to
do: it prevents the file format to change across gtk releases without breaking
applications.

and the bookmarks are just uris, at this time; desktop needs a bit more data -
which gtk can't add if, by changing it we break applications.

there's a page on the wiki: http://live.gnome.org/RecentFilesAndBookmarks

Just an observation: the panel supports named URIs (format: "<uri> [name]")
while GtkFileSel does not seem to.

Also, there doesn't seem to be any GUI way to edit these names.

Looking forward to an API that resolves these issues!

Ian: I'm able to rename these bookmarks using GTK+ 2.8. Right-click any of them
and select "Rename...".

Isn't this done now? Aren't Nautilus Places and FileChooser bookmarks the same thing? 

Not really. nautilus just uses a private file which is not a public gtk interface.
It will be fixed when ebassis recentchooser work lands in glib and GTK+ and when
nautilus uses the official api to access that data.

Created attachment 88722 [details] [review]
[PATCH] Use GBookmarkFile to store file system bookmarks


GBookmarkFile is public API and a much more flexible and expandible format
to store a bookmark. This patch makes GtkFileSystemUnix use GBookmarkFile
to store the bookmarks instead of the home-grown format used by GTK+. The
only downside is the loss of ordering, which can be solved by resorting the
bookmark file contents.
---
 gtk/gtkfilesystemunix.c |  425 +++++++++++++++++++++++++----------------------
 1 files changed, 224 insertions(+), 201 deletions(-)

We'll need a similar patch for the gnoem-vfs backend in libgnomeui.

Could the ordering be added as an extra attribute to the bookmarkfile format ?

Seems to me GBookmarkFile throws away <metadata> elements it doesn't recognize. This makes it very unfriendly to use with shared files, just imagine discarding all <metadata owner="nautilus"> or <metadata owner="http://kde.org/"> elements...

(In reply to comment #10)
> Seems to me GBookmarkFile throws away <metadata> elements it doesn't recognize.

it does only when you save the file - the wonders of a SAX-based parser. I postponed the implementation of this because there were no other users of this API except GtkRecentManager.

> This makes it very unfriendly to use with shared files, just imagine discarding
> all <metadata owner="nautilus"> or <metadata owner="http://kde.org/">
> elements...

for the time being, there are no other users.

(In reply to comment #9)
> Could the ordering be added as an extra attribute to the bookmarkfile format ?

I updated the spec and the ordering of the file should be preserved in the UI and vice-versa, so listing bookmarks using:

  uris = g_bookmark_file_get_uris (bookmark_file, &n_uris);
  for (i = 0; i < n_uris; i++)
    {
      uri = uris[i];

      title = g_bookmark_file_get_title (bookmark_file, uri, NULL);
      ...
    }

will return the same on-disk representation. reordering would simply imply iterating over the shortcuts from the ListStore when creating a GBookmarkFile to be saved.

So, we've recently had some discussion about extending bookmarks to reimplement the 'connected servers' feature that we lost in the transition from gnome-vfs to gvfs. 

In that context, we've talked about maybe moving the bookmark manager functionality to gio.

Yeah, I've been working on the connected-server feature for Nautilus this week (see bug 555331, bug 555332, bug 555333, bug 555334). Currently my patch set stores these connected-servers in GConf but that's hardly ideal. Especially since there's little or no difference to users between connected-servers and bookmarks (except that the former should appear on the desktop etc.)

I'd much rather use bookmarks to both simplify the code and also avoid introducing yet another concept into the desktop shell and our API's. However, the current .gtk-bookmarks approach falls a bit short; we need to stick icons and possibly other meta-data into the bookmark if we were to use bookmarks.

The proposed API that I had in mind for libgio is similar to the GVolumeMonitor API; there'd be

 GBookmarkMonitor

with

 g_bookmark_monitor_get (GBookmarkMonitorKind bookmark_monitor_kind);

for

 G_BOOKMARK_MONITOR_KIND_SHORTCUTS
 G_BOOKMARK_MONITOR_KIND_RECENTLY_USED_FILES

Now, the GBookmarkMonitor class would allow you to enumerate and create GBookmark instances (API to be determined). Also, GBookmarkMonitor would emit ::added, ::removed and ::changed and signals.

GBookmark would be a GInterface and would probably export more or less what GBookmarkFile does today except it would make use of GFile, GIcon and so forth instead of the non-gio types used today.

In addition, the GBookmark would provide some functionality for the user to determine if the given GBookmark is user-writable, user-editable, user-deletable and so forth. Kinda like we have we GConf today.

That's the user-visible API. 

For implementations, libgio would export a GIOExtensionPoint for the class

 GBookmarkMonitorFactory

and gio modules would supply subclasses - the factory class would have a single method g_bookmark_monitor_factory_get_bookmark_monitor_for_kind () along with a priority to resolve where writes end up (maybe also a concept of native monitors like we have GNativeVolumeMonitor).

We'd initially ship the class

 GGtkBoomarkBookmarkMonitor

with libgio for UNIX, and later we can add

 GXBELBookmarkMonitor

that would use GBookmarkFile under the hood. libgio for Win32 and OS X can supply their own types too if it makes sense for these environments to care about user-visible shortcuts and recent files (I think at least OS X has a notion of recent files, not sure).

Also, vendors, ISV's or enterprises can supply their own monitors; it would all get merged using the union monitor / factory approach.

Also, perhaps we'd implement GGtkBoomarkBookmarkMonitor so it makes use of a $HOME/.gtk-bookmarks-sidecar file to store things like icon (it seems to be that .gtk-bookmarks is not extensible). Or maybe we just switch directly to using GXBELBookmarkMonitor. I don't know.

Discuss.

(In reply to comment #14)
> For implementations, libgio would export a GIOExtensionPoint for the class
> 
>  GBookmarkMonitorFactory
> 
> and gio modules would supply subclasses - the factory class would have a single
> method g_bookmark_monitor_factory_get_bookmark_monitor_for_kind () along with a
> priority to resolve where writes end up (maybe also a concept of native
> monitors like we have GNativeVolumeMonitor).

I didn't explain this very well, sorry. The idea is that GBookmarkMonitor uses the factories to create a set of monitors for a given kind of monitor. It might end up with instances of

 GBookmarkMonitorFoo
 GBookmarkMonitorBar
 GBookmarkMonitorBaz

and the idea is that it merges these three instances. E.g. enumeration on GBookmarkMonitor would merge results from all three instances. See GUnionVolumeMonitor in libgio for a similar approach used for volume monitors. Hope this clarifies.

I've written a (mostly finished, but still work in progress) patch for GIO for doing the stuff mentioned in comment 14 and comment 15. See bug 556040 for details.

I think the multiple-implementation types using a union monitor is overkill. It increases the complexity of both the code and the user/sysadmin visible part of the whole system. I.E. if you want to backup or look at/modify the bookmark files directly it gets very complicated to figure out where data is stored.

IMHO we should just pick a format that supports all that we need and is somewhat extensible and only use that (although we might want the implementation pluggable on a less complex level so we can use custom formats for each platform [X,win32,OSX]).

The requirements for desktop forlder bookmarks that I see are:

* Store URI
* Store display name
* Store icon (file or themed icon name)
* Support some way to specify bookmark ordering
  (We support reordering bookmarks in e.g. the sidebar and
   want to show the same order everywhere)
* Should be able to specify whether a bookmark is to be treated as
  a volume
* It should be possible to merge several files as sources (i.e. additional
  files for systemwide mandatory and non-mandatory bookmarks)

Problems I see with XBEL (as per the desktop-bookmark-spec):

* mime type is mandatory for the bookmarks. This is weird, but I
  guess we can just hardcode inode/directory.
* application mandatory. While this makes sense for recently used I
  don't really know what to fill in here for global system folder bookmarks.
* doesn't allow specification of themed icons
* The order of bookmarks is explicitly defined to not have any order

(In reply to comment #17)
> The requirements for desktop forlder bookmarks that I see are:
> 
> * Store URI
> * Store display name
> * Store icon (file or themed icon name)

the desktop-bookmark spec has been amended, in collaboration with the KDE developers, to support named icons as well as full URLs to the actual icon file.

> * Support some way to specify bookmark ordering
>   (We support reordering bookmarks in e.g. the sidebar and
>    want to show the same order everywhere)
> * Should be able to specify whether a bookmark is to be treated as
>   a volume
> * It should be possible to merge several files as sources (i.e. additional
>   files for systemwide mandatory and non-mandatory bookmarks)
> 
> Problems I see with XBEL (as per the desktop-bookmark-spec):
> 
> * mime type is mandatory for the bookmarks. This is weird, but I
>   guess we can just hardcode inode/directory.

that would be expected, yes.

> * application mandatory. While this makes sense for recently used I
>   don't really know what to fill in here for global system folder bookmarks.

I can relax the spec in this case.

> * doesn't allow specification of themed icons

as I said above, this has been fixed. I failed at putting the new spec online - I'll do it ASAP.

> * The order of bookmarks is explicitly defined to not have any order

this has been fixed as well: the order on the file must be the same used to display the bookmarks.

So, then the only question i have left is. How do you handle order between files when merging bookmarks from different places. (The user should imho be free to reorder across source bookmark files.)

(In reply to comment #19)
> So, then the only question i have left is. How do you handle order between
> files when merging bookmarks from different places. (The user should imho be
> free to reorder across source bookmark files.)

good question. at the moment, I don't have an answer other than: when merging preserve the file order and then the parsing order:

  + 01-file.xbel
  +---- bookmark 1
  +---- bookmark 2
  + 02-file.xbel
  +---- bookmark 1
  + 03-file.xbel
  +---- bookmark 1
  +---- bookmark 2
  +---- bookmark 3

so, the order would also be:

  + global    - /etc/xdg/desktop-shortcuts.xbel
  + user      - $XDG_USER_DATA/shortcuts.xbel

what kind of metadata would you want to add in case you have bookmarks spread across multiple files? or do we add something similar to the applications.menu XML file that determines ordering?

If each bookmark had a "position" int metadata that could be used to specify order (non-positioned bookmarks go at the end in file order).

However, the problem then is that such metadata need to be per-user, even for the global files... So, maybe what you rather want is a that the user and global bookmarks look like normal, but then we add a new section in either the user file or a separate file that just contains an ordered list of uris, and for each such uri that is in the bookmarks that order is used, not listed ones go at the end.

There is some more per-user metadata that you may want to associate with global bookmarks, e.g. to allow the user to hide/delete global bookmarks.

*** Bug 577987 has been marked as a duplicate of this bug. ***

Ping? 

I'd really like to reopen the discussion on this. The bookmark location changed from $HOME/.gtk-bookmarks to $XDG_CONFIG_HOME/gtk-3/bookmarks, and there's no convincing me that the location and the format of the file won't change again to something else (Gtk 4?) It'd be nice to have some API I could rely on so I don't have to keep forward porting code to handle bookmarks.

If gtk4 comes around, you will have to do some porting anyway (otherwise it would be 3.x). 

I don't think this bug needs to stay open any longer.