xfdesktop menu is getting awesomer

[Brian J. Tarricone]

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 ^_^.

	-brian