Re: [RFC] Simple file monitoring API for GLib

On Tue, 2006-05-09 at 13:11 +0100, Emmanuele Bassi wrote:

> This little API should be more useful that just monitoring the recent
> files storage, indeed; this task just forced me to sit down and
> implement this API. :-)

That's the thing - people will see that gnome-vfs has a file monitoring
API, and that Glib has one as well, and they'll think "the Glib one is
at a lower level, so it must be BETTER!".  And they'll start abusing it,
they'll see that it doesn't scale, and blame us.

Oh, and also we'll have two file monitoring code bases to maintain.

> The short-lived case is not interesting; but we might also want to have
> a more long-lived display of the recent files list - like as an applet,
> as a nautilus view, or using gimmie.  I agree that all of these cases
> might as well use gnome-vfs to check the recent files storage, but at
> that point we would need a gtk_recent_manager_reload() function in order
> to let the GtkRecentManager to reload its data - which is a bit awkward.

I don't think it's inconvenient at all.  Those long-lived,
whole-desktop-ish apps are special anyway.

The *real* problem is that we haven't decided to bite the bullet and
either completely remove gnome-vfs, or to put it below the GUI part of
the GNOME stack.  GtkFileSystem is already a mess because we have to
maintain two pretty complex implementations:  the Unix backend, and the
gnome-vfs one.  A file monitor in Glib will create exactly the same


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]