RecentManager and win32

[Emmanuele Bassi <ebassi gmail com>]

Hi all.

As you know, I've been working on the recent files stuff, and since the
API design has slowed down a bit to something that I consider basically
frozen (at least, for the RecentManager object), it has come - allow a
moment for building suspence and for fetching Christopher Lee in order
to do the scary voice-over -

	The Dreaded Time of Thinking of Other Platforms!

(Thank you, Mr. Lee; and, no: I didn't hold you responsible for Episode
II and III)

I've done some "homework", and (thanks to Federico for pointing me in
the right direction) read the API for the MRU list in win32-land, and
came up with some sort of strategy; I'd like to know if this strategy is
feasible, and if anyone of the fine people doing the hard work of
porting GTK to win32 is willing to spend some time helping me on it.  Or
hitting me very hard with a clue-by-four.

+++

* Background
============

Win32[1] has its own Most Recently Used list.  It is stored inside the
registry, in a per-application sub-tree; that is: each application
directory has its own MRU list.  A file is added to the MRU list using
its path, and nothing else.

The Gtk-way is/will be: we store everything inside one file, and we
store it by URI; each application "registers" a URI, and so each URI
"item" has several "application" nodes [for a detailed description, you
should see the wiki page at
http://live.gnome.org/RecentFilesAndBookmarks - especially the desktop
bookmark spec].

* Requirements
==============

1. The RecentManager requires more meta-data, but also offers more
meta-data; in contrast, Win32 shell API is a bit simple: it really
requires just a path.

2. The meta-data is needed on Unix - at least on Gnome; if an
application has registered a recent file, it should be used to re-open
it, because there's a big chance that the user really wants this.

3. The meta-data is really not mandatory on win32.

* Strategy
==========

Obviously, we can't have two APIs, so the best thing that I could come
up with was:

1. we use, for the recently used resources list, the same storage system
on both Unix *and* win32: a dot file inside $HOME, which stores
everything using an XBEL dialect;

2. plus, protected by arch-dependent #ifdefs, when we register every new
item inside *ours* recently used resources list, we also register it
inside windows' MRU list, using the win32 shell API.

By doing this, we keep the same meta-data on both archs, but we make
windows aware of what we are registering.

The implementation should be trivial enough: since we take a URI, we can
convert it to a path, and then register it using a single call to
SHAddToRecentDocs().

Insights, LARTs or flames are welcome.  Well, flames are less welcome,
but: hey, whatever... :-)

Regards,
 Emmanuele.

+++

[1] Okay, note that I talk only about win32 and not of, say, OSX; this
because OSX has an abstract class handling documents, and registration
of recently used documents; class which we don't have - and most likely,
we won't have.  So, if anyone whishes to hack on supporting the recently
used files under OSX, please: feel free to ping me.

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