EggRecent [was Re: libomelette [was Re: glib unicode regular expression api]]

[Federico Mena Quintero <federico ximian com>]

On Mon, 2004-07-05 at 17:34 +0200, Anders Carlsson wrote:

> The problem with putting it into gtk+/glib is that it'll work on Unix
> only. IIRC, for example Windows has another specification for recent
> files which means we'd have to get someone to review that, make sure
> that the EggRecent API has the least common denominator, etc. (Which
> isn't a bad thing of course, but it does add extra work). Gtk+ is
> designed to be (more or less) cross-platform, gnome isn't really.

This is similar to the situation we have with bookmarks in the file
chooser.  All three backends use a ~/.gtk-bookmarks file.  The Unix and
Gnome-VFS backends use exactly the same code, but the Win32 backend uses
different code for reasons I can't understand; ideally it should use the
Win32 APIs to manipulate bookmarks, but people say they are a pain to
use as they involve COM and whatnot.

I assume that Win32 has its own mechanism for recent-files.

During my GUADEC talk some gentleman whose name I can't remember asked
whether EggRecent is ideal in the form it exists right now:

- When you create files, you save them via a GtkFileChooser.  Why can't
it add the recent-files entry on its own, without the program having to
do anything by itself?

- Likewise, when you open a file, you either do it with a GtkFileChooser
or by some action with the file manager (Nautilus).  Couldn't that
process involve adding a recent-files entry automatically?

Also, in the very near future I would like to add a list of recent-files
to GtkFileChooser.  It makes no sense to have that available everywhere
but *the* file chooser itself!  This means we need the EggRecent stuff
at the Glib level, or possibly GTK+.

In any case, we should clean up the EggRecent API a bit:

- egg_recent_model_add() is rather useless as it doesn't set a group for
the new item.  So, your File menu can't have those items in it.

- egg_recent_item_get_uri_utf8() makes no sense.  URIs are, by
definition, in ASCII.  In contrast, egg_recent_item_get_uri_for_display
() does make sense, as gnome-vfs may unescape it and such.

- Why do we need egg_recent_item_set_mime_type()?
egg_recent_item_new_from_uri() computes the MIME type automatically.
Isn't that what we want to happen in all cases?

- EggRecentItem is a boxed type, not a GObject, so it has its own ref()
and unref() functions.  These are registered correctly, so why do we
need to expose them?  E.g. can't one just use g_object_ref()/unref() on
EggRecentItem rather than custom functions?

Also, as for implementations on particular systems (Unix/Win32), we
could probably have a GTypeInterface for recent-files and then load the
implementations in the same modules as are used for GtkFileSystem.

  Federico