Current situation

The recent-files code lives in libegg. Every application cuts&pastes that code. Apps include their own changes, which do not always get merged back into libegg, or propagated to other applications. The recent-files code really needs to be in a platform library.

• EmmanueleBassi: I've mailed James Willcox in order to see if he's still too busy for maintaining the recent-files module. As of today, I did not get a reply from him. In the meantime, I'm writing a new implementation of the recent-files module as a platform library. I intend to make it basically similar to the recent-files, plus the remarks expressed here, plus a sane widget set (not like the EggRecentViewGtk madness I had to use).

The API has some inconsistencies. FIXME: link to mailing list discussion.

• EmmanueleBassi: The API is also really binding un-friendly (if there's such a word :-)). See bug gnomebug:159603.

GtkFileChooser has a bookmarks system. It was only visible within the file chooser itself, until gnome-panel-2.10 started reading ~/.gtk-bookmarks on its own. This is good for users, as it lets them access their bookmarked folders easily. This is bad for GTK+ as it prevents it from changing/enhancing the .gtk-bookmarks format.

Bookmarks in GtkFileChooser don't have editable names; the user sees them as the basename of the folder in question. So if you bookmark "/foo/bar" and "/baz/bar", you get two "bar" entries and no way to distinguish them. Ignoring the lack of tooltips, it would be good to be able to give meaningful names to bookmarks --- bookmarking /cvs/gtk+/docs/gtk/html gives you a bookmark with "html" for its name, which is not very meaningful. MatthiasClasen: In GTK+ 2.8 bookmarks will have editable names.

From the user's viewpoint

Users want to define frequently-visited folders.

Probably frequently-visited files as well.

Bookmarked files are not really the same as recently-used. You may want a bookmark to ~/todo.txt even if you don't check it every day.

• EmmanueleBassi: Recent files and bookmarks shows basically orthogonal issues; bookmarks are low-access rate, long lifetime objects, while recent files are high-access rate, short lifetime objects. Both issues are solved in the same solution space, that is the recent files spec from fd.o. We could create a common API, and just have a flag saying "hello, I'm a bookmark" or "hi, I'm a recent file", and let the application sort it out.

You do want recently-used directories as well as files.

Why are there so many places to obtain desktop bookmarks (panel, file chooser, Nautilus)? Can't they be shown in a single, well-visible place like the desktop itself?

This is outside the scope of web bookmarks.

• EmmanueleBassi: also, you might want a list of recently used applications (see future plans below), something like the shell history. We might use the session manager to gather the command line used to launch an application.

Implementation

Each bookmarked folder/file should be a <uri, name> tuple. Rationale: seeing "To-do list" in your bookmarks is nicer than "todo.txt". Likewise, "GTK+ manual" is better than "html" from "~/src/gtk+/docs/reference/gtk/html".

Each recent item is currently a <uri, name, timestamp, mime-type, groups, private> tuple. Are groups well-defined?

• PaoloMaggi: I don't think this info are enough. A recent item should be described by something like (it is only an example, it does not mean we will have to use XML):

<recent-item timestamp="1028181153">
   <uri>file:///home/jwillcox/testfile.txt</uri>
   <mime-type>text/plain</mime-type>
     <applications>
        <application timestamp="1028181153" private="no">
           <name>gedit</name>
           <exec>gedit --new-window %u</exec>
       </application>
       <application timestamp="1028181034" private="no">
         <name>gvim</name>
         <exec>gvim %f</exec>
       </application>
     </applications>
</recent-item>

• Where <mime-type> is optional. <applications> contain the list of apps that have added the item (the same item can be added by more than one app). For each app we need to know: <name> it is the equivalent of the current group, and an <exec> command that have to be used by the panel to open the item (I don't think using gnome_vfs_open is enough here). If an app mark the item as private, it means that the panel must not display it in its recent files list (it will only displayed in the recent file list of the app itself). Like you, I started writing a Wiki page about EggRecent, ATM it is unfinished. BTW, I have some idea about the content to write there, if you want we can discuss it (I don't think I will have the time to implement it). The page is RecentFiles

  • EmmanueleBassi: Paolo, you wrote that the recent-files is currently unmaintained. Currently, there are many patches floating around in bugzilla (open bugs for recent-files), some of them are already in users' code. We need to apply those to libegg, before improving the current situation.

If we add a "bookmark" element to each recent-files item, then those could be the bookmarks. What about groups? Along with the "private" flag/element, they could be used to easily implement per-app bookmarks. I'm not convinced that this is a good idea, but who knows.

• EmmanueleBassi: We could use groups, since Paolo proposed the ability for applications to register themselves inside a bookmark. The spec could define the "Bookmarks" and "Recent Files" groups. See my draft.

RossBurton: one thing I'd like to see in future recent documents specs is an automatically incrememented "count" attribute (if an item is already in the list when it is added the count is incremented) on each item, and associated most/least-frequently used sorting types. The main use case for this is a "most frequently used programs" applet which displays the applications which are started the most (by making the panel put all .desktop files it launches into the recent list).

• EmmanueleBassi: each application that has registered a bookmark should have a "counter" or you are thinking of a counter just for the bookmark item?

  • RossBurton: either work for me, I can see arguments for both PoVs. In my use-case a counter per group would be most logical.

EmmanueleBassi: the spec I proposed to freedesktop.org uses XBEL instead of GMarkup. This places the object for storing bookmarks outside Glib for the time being (I'm writing a generic XBEL parser using GObjects and libxml2 right now, and will include it inside the library). Anyway, here's an example of a bookmark:

<xbel version="1.0"
      xmlns:bookmark="http://freedesktop.org/1/desktop-bookmark">
  <bookmark href="file:///home/ebassi/bookmark-spec/bookmark-spec.xml">
    <title>Bookmarks Storage Spec</title>
    <info>
      <metadata owner="http://freedesktop.org">
        <bookmark:mime-type>text/xml</bookmark:mime-type>
        <bookmark:applications>
          <bookmark:application name="GEdit" count="2" exec="gedit --new-window %u" timestamp="1115726763"/>
          <bookmark:application name="GViM"  count="7" exec="gvim %f"  timestamp="1115726812"/>
        </bookmark:applications>
        <bookmark:groups>
          <bookmark:group>Editors</bookmark:group>
          <bookmark:group>Recent Files</bookmark:group>
        </bookmark:groups>
      </metadata>
    </info>
  </bookmark>
</xbel>

End Point - Future dreams

The main problem is that as all in freedesktop.org recent files stuff is designed to just work and satisfy standard users. But here I'll try to describe, how it should really look.

To be honest, it should be named "Recent Tasks". User should open menu and see the following:

• Edit a.txt
• View Matrix moview
• Listen radio station
• Sync Palm
• Write mail to Michael Meeks about OO bug.

So, the idea that is should be history of tasks with ability to give them priority, select tasks from groups, forget some tasks, plan tasks in the future.

From the implementation I think it should be service integrated to Session daemon (Is there a page about it on the wiki?). With very simple interface - register task (Task class and data to reproduce task, for example uri of document), register task creator (Task class and UI to create task), register task executor (Execute task from data from task creator).