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 freedesktop.org
* 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
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.
Proposed High Level Architecture