Recent Files

Many applications choose to have a menu containing a list of recently used files, which can be used as an alternative to opening a file selector. GNOME, and KDE applications have done this for quite some time, and probably others have as well. This specification aims to do the following things:

* Provide a standard mechanism for storing a list of recently used files (really, URIs)

* Allow for notification of changes in the list

Problems of the current specification

The current specification can be found on

* It is defined at the file level (I think it should be defined at an higher level, for example as a DBUS service)

* Even if it is on Freedesktop, it seems only GNOME is using it.

* It is not well defined how file-locking should work

* It requires a mechanism (like FAM) to monitor file changes

* others???

EmmanueleBassi: possibly, a short description of the task involving the file (e.g.: Editing shop list.txt), and a way to launch the application that registered the file, in case it did not have a registered MIME type.

Problems of the current implementation

The current implementation can be found in libegg/recent-files 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.

* It is un-maintained

* It lacks documentation

* There are several API inconsistences

* It seems to have problems with file locking (and probably a potential deadlook)

* Low code quality

* GNOME specific (I think we should split it in a desktop independent part, the model, and in a GNOME/GTK+ specific part, the views).

EmmanueleBassi: I've collected some patches lying around in bugzilla when I worked on the eggrecent perl bindings, and I'm willing to bite the bullet and maintain this module.


* req1

* req2

Proposed High Level Architecture


Attic/RecentFiles (last edited 2013-11-23 00:47:28 by WilliamJonMcCann)