After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 336671 - recent file monitoring
recent file monitoring
Status: RESOLVED DUPLICATE of bug 487375
Product: gtk+
Classification: Platform
Component: Class: GtkRecent
Other Linux
: Low enhancement
: Small feature
Assigned To: gtk-bugs
Emmanuele Bassi (:ebassi)
Depends on: 340746
Reported: 2006-03-30 21:25 UTC by Christian Persch
Modified: 2007-10-19 16:25 UTC
See Also:
GNOME target: ---
GNOME version: ---

first rough implementation (4.65 KB, patch)
2006-05-03 11:29 UTC, Emmanuele Bassi (:ebassi)
needs-work Details | Review

Description Christian Persch 2006-03-30 21:25:40 UTC
The recent file manager polls the recent file once every second.
I think there should be a way to provide for more efficient file monitoring, like using a gnome-vfs file monitor.
That could be either the addition of a gtk or glib file monitoring backend; or, simpler, just a way to make the recent manager not poll and to force it to reparse the recent file which I'll call from my own file monitor.
Comment 1 Emmanuele Bassi (:ebassi) 2006-05-03 11:29:52 UTC
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.
Comment 2 Matthias Clasen 2006-05-03 16:30:50 UTC
I think the documentation should mention that the use case for these functions
is app-side file monitoring to avoid the toolkit-side polling.
Comment 3 Emmanuele Bassi (:ebassi) 2006-05-03 16:41:30 UTC
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.
Comment 4 Christian Persch 2006-05-03 17:55:26 UTC
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 {
} GtkFileMonitorEvent;

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

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

void gtk_recent_manager_set_monitor_hooks (GtkFileMonitorHook hooks);
Comment 5 Emmanuele Bassi (:ebassi) 2006-05-07 20:22:19 UTC
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.
Comment 6 Matthias Clasen 2006-06-02 02:57:32 UTC
given that the glib file monitoring api is controversial, moving off 2.10 api freeze.
Comment 7 Christian Persch 2006-06-18 14:52:45 UTC
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) ).
Comment 8 Federico Mena Quintero 2006-09-15 15:01:19 UTC
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.
Comment 9 Matthias Clasen 2006-09-15 17:05:47 UTC
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)
Comment 10 Allison Karlitskaya (desrt) 2006-09-22 16:37:47 UTC
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).
Comment 11 Matthias Clasen 2006-09-22 17:05:13 UTC
The changed signal is part of the API. We can't just make that go away...
Comment 12 Emmanuele Bassi (:ebassi) 2007-10-19 16:25:35 UTC
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 ***