1. Current situation

We should probably merge this page with RecentFilesAndBookmarks

We currently have a few default locations like Trash, Home, Desktop, Documents and Templates which show up in various places so the user can easily access these standard places. On top of that the user can add their own standard places by adding gtk-bookmarks.

Currently the 'Places' menu on the gnome-panel lists some of these standard locations and also lists gtk-bookmarks. However, Nautilus shows different locations in the Places menu and doesn't support gtk-bookmarks. These places are also hard to get for other applications and there is no library which lists places and is able to manipulate gtk-bookmarks.

2. Possible Solution

So what we need is a central place to keep track of gtk-bookmarks and common locations.

<seb128> the plan would be to:
<seb128> - get a gtk API to manage the bookmarks (get them, create one, ...)
<seb128> - update gnome-panel and nautilus to use it .. not sure on how to sync them
<seb128> ie: with a lib, or copying the same code

The last part probably requires some discussion. Do we make a library for it? Integrate it with another library?

FranciscoCamenforte: I think this would be nice to be integrated in next generation gnome-vfs or Freedesktop's DVFS. A single library for bookmarks looks quite unnecessary to me since it'd be a small feature, and more proper to be in the library that takes care of files/documents access.

FedericoMenaQuintero: take a look at the draft version of RecentFilesAndBookmarks. I think a revised version of the recent-files spec would solve most of the problems described here.

MichielSikkes: The GTK-bookmarks stuff will be a great solution if there's a nice and clean API for it. I've heard that the gtk hackers are working on it. However we also need to have some static locations like Trash and Desktop. Is there any way we can build in/hard code/specify static locations with gtk-bookmarks?

EmmanueleBassi: the code in libegg/bookmarkfile expose an API for creating bookmarks and storing them using XBEL; it is used by the libegg/recentchooser code in order to store the recently used resources (as bookmarks to actual resources). We could simply define a standard location for a storage file (e.g. $XDG_DATA_DIR/desktop-bookmarks/locations.xbel) and then use the BookmarkFile object to access them, much like we use GKeyFile to access the desktop entry files. System Administrators could define standard, system-wide, locations; applications could install their own default locations (e.g. Sound Juicer might add the "My Music" location), and users might add them - as "shortcuts".

YevgenMuntyan: please do not forget about private per-application bookmarks and please please consider bookmarks which are not 'uris'. E.g. lines inside of text files. And please do not forget about custom icons

• I think you are misunderstanding what a "bookmark" is, in this case. A desktop bookmark is an URI-based entity, no more, no less. Everything needing something else than a URI belongs to a different problem space; win32, for instance, addresses this issue (so to speak): every application has access to a circular queue with 24 available slots inside the Registry (see CreateMRU, EnumMRU functions inside the Windows API); in any of these slots you can store just a string. On "our side of the pond", this could be doable using a per-application key file, but I don't think this belongs to GLib or GTK: it's something really application-specific. As for custom icons inside bookmarks: since we are dealing with URIs, everyone might implement an icon association the way he likes it. Inside the RecentManager object used for recently used resources, we use the icon bound to the (stored) MIME type of the item (I also have code in my development trunk that retrieves the thumbnail for the item's URI, using the freedesktop.org specification for thumbnails). There's no way for us to store an icon inside XBEL, without actually adding another meta-data field containing the URI to that icon, but this could be tricky. We could consider adding this feature once the code has reached GTK, if there's enough request.

  • YevgenMuntyan: Let me address couple of these issues:

    >> A desktop bookmark is an URI-based entity, no more, no less. Yes, it's true, if you define it so. But please consider wider notion of 'bookmark', to make life of application developers easier, and make gui consistent. The user does not really care about uris or other technical details, he likes nice gui. If I have an ssh frontend, why wouldn't I have menu similar to bookmarks menu in file manager, for example? Or, if I have a text editor, why my documents bookmarks should look different from file bookmarks in file manager or wherever it's gonna be used.

    • EmmanueleBassi: developers will use a URI. And users see and use URIs all the time. Opening to the definition like a bookmark is any UTF-8 encoded string would be an hell to both standardise and to code; and mind me, standardise is the key, here. Feel free to define a new library, and a new specification for you issue.

      • Hehe, let's talk about input entry in GtkFileChooser? Okay, sorry for my misunderstanding. Stupid me, I saw word 'bookmark' and decided that we are going to get an easy way to deal with bookmarks in gtk. Mind me, "standardise" is worth nothing without conforming implementation. And new library with new specification is worth even less. The application will just implement its own stuff, as always. Well...

    >> ...it's something really application-specific. It is application-specific atm because there is no easy way to create nice gui. Nice bookmarks stuff would be one more step toward easy nice gui.

    • EmmanueleBassi A nice GUI is not an issue here. Once you've defined a spec, you could write off a nice UI for it - but (and I can't stress it any more than this) you must define a spec before; any UI will follow.

    >> As for custom icons inside bookmarks: since we are dealing with URIs, everyone might implement an icon association the way he likes it.

    No, this one is not about applications, it's about GtkFileChooser - I create a bookmark, and I want it to have nice pig icon, to easily distinguish it from other bookmarks. By the way, bookmarks already can be renamed, and it doesn't fit into "uri and nothing else" scheme either.

    • EmmanueleBassi: I never said URI and nothing else; in fact, by saying that icons are now obtained throught the MIME type stored inside the meta-data section of the storage format, I implicitely said that we store meta-data for that URI; please, take a look at the specification and at its current implementation before commenting it: it'll make things easier for me, since I don't have to actually explain what it does and how it does.

    >> There's no way for us to store an icon inside XBEL, ...

    Is this a good reason for me as a user not to have nice pig icon for my favorite "foo" folder in GtkFileChooser.

    • EmmanueleBassi: No, but it has nothing to do with the storage format. We could add a bookmark:icon element to the meta-data, retaining backward compatibility; but it must be requested - as you did. Drop by to the next GTK development meeting, and let's discuss it. I'll request a bugzilla component entry for the recentchooser/bookmarkfile modules, and I'll begin tracking bug/enhancement/feature request as soon as I can.

    Please, consider a more complicated (or more simple?) notion of bookmark, the one which does not fit into uri stuff, and can not be saved nicely in XBEL or whatever technicality is involved here. Please do not create a thing which will be used in 1) GtkFileChooser, 2) Nautilus, 3) in 1) and 2). Let gnome have cool menu or whatever it has, but why not also make a really nice and usable thing in GTK for GTK applications?

    • EmmanueleBassi: You must understand that we are trying to solve a (simple) problem, here: bookmarks to defined places mapping locations onto the file system that have to be accessed by the FileChooser (and, tangentially, by any other application dealing with the file system, e.g. Nautilus) and can be defined not only by common users, but also by administrators or by applications - and recently used resources. This is our problem space. Your request overlaps a bit - specifically on the issue of bookmark - but it's another issue altogether. What you want is an opaque data structure used to store application-specific data, either ordered or un-ordered, and with a common UI around it. As I said, the implementation is so application-specific that we the only solution that comes to mind is to provide a GInterface and let application developers implement it. This could indeed be feasible, but it does not address the desktop places or the recently used resources issue.