Re: Recent Files Manager in libegg

[Emmanuele Bassi <ebassi gmail com>]

Hi Mark,

On Fri, 2005-07-15 at 10:32 +0100, Mark McLoughlin wrote:
> Hi Emmanuele,
> 	(I have to admit that this is the first time I've noticed this
> proposal. I can't blame you for that - you clearly have been writing
> proposals and discussing those proposals on various lists. Bear with me
> while I go back to the beginning, though ...)
> 
> 
> 	Looking over your work:
> 
>   http://devel.emmanuelebassi.net/software/recent-chooser-commit.diff
>   http://live.gnome.org/RecentFilesAndBookmarks
>   http://devel.emmanuelebassi.net/papers/bookmark-spec.html
> 

> 	Certainly, it seems a little premature to dump the .recently-used
> format for a proposed "common desktop bookmarks" format, before the new
> format has seen any use for genuine bookmarks - e.g. by web browsers.

I'll try, and address this point which is the main concern about my
"recent stuff" proposal.


Let's start with saying that it'll be the best thing that we share the
recently used files data across multiple desktop environments; it's the
approach taken for most of the architectural choices that has been made
recently (see the menu-spec, the shared-mime-spec, the
desktop-entry-spec, etc.).

Also, let's state clear that the currently defined recent-spec is not
"widely adopted", as it is implemented just by us, and us alone; also,
it seems that there's no intention to implement it by anyone else; that
spec has been out there for three years now, it hasn't been used by
anyone, it hasn't been updated, and it's still marked as a draft.

It's not bad: we can live with having a storage format used just by us;
it's not optimal, but, hey: nobody uses KDE, right? ;-) But we've never
said that the recent-files format was set in stone, or even finalized;
there's much room for improvement, as to be seen on the wiki page (see
the /OldDiscussion page for storage format discussions and
improvements).

My proposed desktop-bookmark spec was designed with recent-files in mind
(and you can see it from the meta-data, which roughly maps the
recent-files-spec meta-data), and then it occurred to me that the
bookmarks we are using into the GtkFileChooser are a generalization of
the "recent file" concept; or, better, that which we call recent file is
but a bookmark with another name.

What made me think that a recently used file is semantically equivalent
to a "bookmark"?  Both are pointers to a resources, indexed by a URI;
both are created by the user to relatively fast access to a specific
resource; both have some meta-data in common (last access time, last
modification time, a name to be used instead of (part of) the URI); both
might require some meta-data for smarter (and faster) access, such as
the MIME type; both should have a way to store the name of the
applications that have effectively stored them, the number of times they
were registered, etc.  Also, as I came to realize, bookmarks inside the
GtkFileChooser are used for fast access to recently used directories
(and with Nautilus exposing the Gtk bookmarks, I expect this behaviour
to spread out even more).

To make a long story short, the format was to be expanded in order to
make it useful again, and after discussing with the people on xdg-list,
the XBEL format was proposed instead of a GMarkup format (which was what
I originally proposed to use; in fact, my original spec draft was a
re-hash of the recent-files spec, with the ideas expressed on the wiki;
it was shot down without much mercy).  Why is an XML dialect preferable
over another?  Because GMarkup is used just by us, while XBEL is an
established standard (Epiphany and Galeon use it; and the KDE people
already store their bookmarks with it); because XBEL has by default some
meta-data that the recent-files spec lacks (namely, the "title" element,
used for displaying a custom name instead of the link URI, and a "desc"
element, used for the description), and which was going to be added
anyway; because it's extensible, providing opaque containers for our
meta-data; because GMarkup is suited for parsing small chunks of data,
which kept the recently-used file size small (500 files, enforced).

+++

Finally, as for the "desktop bookmark" concept: I like to think of it as
a bookmark used just in the desktop context; it should be used, for
instance, into the GtkFileChooser and in Nautilus, or by any other
applications - since Gtk does not expose an API for accessing and
changing the .gtk-bookmarks file, and the format of this file does not
allow meta-data needed for applications to save their own bookmarks, or
to make them private, or tag a bookmark with some keyword, etc.

So, a recently used resource could be seen as the first implementation
of a desktop bookmark concept.

Kind regards, and thanks,
 Emmanuele.

-- 
Emmanuele Bassi <ebassi gmail com>
Web site: http://log.emmanuelebassi.net