xfdesktop menu is getting awesomer

[Jannis Pohlmann]

On Mon, 19 Mar 2007 17:40:51 -0700, Brian J. Tarricone wrote:

>
>
> On Tue, 20 Mar 2007 01:08:56 +0100 Jannis Pohlmann wrote:
>
> >On Mon, 19 Mar 2007 16:33:06 -0700, Brian J. Tarricone wrote:
> >
> >> On Mon, 19 Mar 2007 21:20:39 +0100 Jannis Pohlmann wrote:
> >>
> >> >As a workaround you could perhaps call
> >> >
> >> >   frap_menu_shutdown();
> >> >   frap_menu_init("XFCE");
> >> >
> >> >if that's possible for you.
> >>
> >> Bah, that sounds slow, no?  It's fine to cache, but you need a way
> >> to invalidate the cache... either let the user do it with API, or
> >> do it in frapmenu by keeping around a list of mtimes and stat()ing
> >> the files when you next go to use the cached data.
> >>
> >> I don't have anything right now that requires having more than one
> >> root FrapMenu allocated at a time, so your workaround should be ok
> >> for the time being.
> >
> >Most time is spent on parsing the desktop entries, so invalidating
> >the cache shouldn't be much faster than restarting FrapMenu
> >completely. There's going to be some kind of monitoring inside
> >FrapMenu which will do what you need soon.
>
> Well, I've already implemented monitoring using thunar-vfs and the
> various frap_whatever_get_filename() functions so I know when I need
> to regen the menu.
>
> If you want to do that in FrapMenu, perhaps offer the ability via API
> to set a function vtable for doing monitoring?  Sorta like how with
> glib you can set threading or memory functions.  So something like:
>
> struct FrapMenuMonitorVtable
> {
>     gpointer (*monitor_file)(FrapMenu *menu,
>                              const gchar *filename,
>                              gpointer user_data);
>
>     gpointer (*monitor_directory)(FrapMenu *menu,
>                                   const gchar *filename,
>                                   gpointer user_data);
>
>     void (*cancel_monitor)(FrapMenu *menu,
>                            gpointer monitor_handle);
> };
>
> So then I could plug in my own implementation using thunar-vfs, or
> inotify, or FAM/gamin, or whatever, and frapmenu would just handle
> knowing what files/directories need to be watched, and provide some
> kind of function like
>
> frap_menu_monitor_notify_change(FrapMenu *menu,
>                                 const gchar *path);
>
> or whatever so the monitor implementation can tell FrapMenu that
> something changed.  That way you're not forcing dependence on any
> particular file monitoring system, and users could just not make use
> of it if they didn't want to.
>
> Barring this approach, it would be nice to have the FrapMenu be able
> to emit some kind of "contents-changed" signal so I could know when to
> regenerate particular menus.  Since overall menu generation is pretty
> fast, maybe it makes more sense complexity-wise just to regenerate the
> entire menu from the root any time anything changes.  I dunno.
>
> Anyway, there's probably more to it; just an idea to get the ball
> rolling.  Let me know how it turns out ^_^.

I really like this idea. xfdesktop and Thunar will be the most
important FrapMenu users and both already use thunar-vfs which includes
monitoring support. This would make integrating FrapMenu pretty easy -
and would save me a lot of time, hehe.

Would it be ok to call the cancel_monitor function in
frap_menu_item_finalize and frap_menu_finalize? Because this is the
best solution at my end.

  - Jannis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.xfce.org/pipermail/xfce4-dev/attachments/20070320/76532426/attachment.pgp>