Created attachment 64735 [details] [review]
first rough implementation

this implements a freeze/thaw pair that blocks all the *read* operations for a recent manager instance; the writes are kept, as we must update the storage files when the list we hold is changed.

it also adds a force_update function which forces a read if the file has been changed; maybe the check on the mtime is redundant in case you are using a event notification system like gnome-vfs, but I don't think it hurts.

I think the documentation should mention that the use case for these functions
is app-side file monitoring to avoid the toolkit-side polling.

maybe we should make sure that the screen singleton recent manager isn't freezable, otherwise we could not be able to find an owner for resuming the polling, once the application has quit.

This API doesn't seem too practical to me, since it'll require programmer intervention for each recent manager object. What I was after was more like a hook which could be set from libgnomeui's gnome-program initialisation hooks, so that *all apps that use libgnome* would *automatically* use gnome-vfs file monitoring for the recent file.

Something like this:

typedef enum {
  CREATED,
  CHANGED,
  DELETED
} GtkFileMonitorEvent;

/* (handle, uri, reason, user_data) */
typedef void (* GtkFileMonitorCallback) (gpointer, const char*,
                                         GtkFileMonitorEvent, gpointer);

typedef struct {
  gpointer (* start_monitor) (const char *uri,
                              GtkFileMonitorCallback,
                              gpointer user_data,
                              GDestroyNotify destroy);
  void     (* stop_monitor)  (gointer handle);
} GtkFileMonitorHooks;

void gtk_recent_manager_set_monitor_hooks (GtkFileMonitorHook hooks);

I've opened a bug for a simple file event notification API inside glib: bug #340746; I'll make this bug depend on that one.

given that the glib file monitoring api is controversial, moving off 2.10 api freeze.

So can we please at least provide a way not to monitor and force and update, like the patch from attachment 64735 [details] [review] does? (Although IMHO those freeze/thaw functions should just be unified into one gtk_recent_manager_set_monitor_file (GtkRecentManager*, gboolean) ).

Why do we need to monitor the recent-files storage at all?

Currently, the user has to do *something* to bring up a list of recent files:  click on the File menu, etc.  The recent-files storage only needs to be re-read when the user performs that action.

Once we move to a recent-files display that is always on the desktop (like Gimmie's), we *will* need a way to monitor the storage.  That can be easily done by the calling app.

For the record, the Fedora gtk2 rpm has a patch to use fam.

Federico, the panel already relies on the changed signal of GtkRecentManager
to change the sensitivity of the recent files menuitem. Not monitoring the
recent files storage breaks that (as I noticed when the monitoring was broken
for a while in 2.15.x)

I really like Federico's idea.

Also, the sensitivity of the menu item could just as easily be determined when the menu is shown.  I can't imagine it will be very laggy (if it's laggy then it shouldn't be running regularly in the main loop anyway).

The changed signal is part of the API. We can't just make that go away...

really a duplicate of bug 487375

as soon as we have GIO/GVFS and GTK+ can use it, I'll port GtkRecentManager (which now stat()s every 5 seconds using the seconds granularity timeout) to GFileMonitor.

*** This bug has been marked as a duplicate of 487375 ***