FrapMenu change notification (was Re: xfdesktop menu is getting awesomer)

[Jannis Pohlmann]

On Tue, 20 Mar 2007 14:27:18 -0700, Brian J. Tarricone wrote:

> On Tue, 20 Mar 2007 21:14:40 +0100 Jannis Pohlmann wrote:
>
> >On Mon, 19 Mar 2007 17:40:51 -0700, Brian J. Tarricone wrote:
> >
> >> 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.
>
> Also it avoids a circular dependency if you wanted to use thunar-vfs,
> since it's possible thunar proper would want to use the menu, but
> since thunar-vfs is in the same tarball, it would need to be built
> before the menu... and after the menu... argh.  This way FrapMenu
> doesn't actually depend on *anything* extra.
>
> >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.
>
> I don't see why not; that sounds ok to me.

Great. Not much work then, hehe.

> BTW, how were you planning on doing the signals?  Based on how I think
> xfdesktop might use this, I'd want to know the following things:
>
> 1.  When a new FrapMenuItem, FrapMenu, or FrapMenuSeparator gets added
> to an existing FrapMenu.

Emitting a signal when a FrapMenuItem is added to the menu will be
easy. The other ones won't be possible, mainly due to the reason that
they're all part of the same .menu file. When a .menu file changes,
everything has to be rebuild (there's no way to do .menu format XML
diffs, huh?). the easiest way here would probably be to keep the root
menu object alive, destroy all its children, rebuild it completely and
emit some kind of "reload" signal.

> 2.  When a FMItem, FMenu, or FMSeparator gets removed from an existing
> FMenu.  So the same as #1, just the reverse.

Same as #1.

> 3.  When an existing FrapMenu{,Item} is changed somehow (name, icon
> name, command, etc.). (Presumably, separators don't get changed; just
> added or removed.)  So:

Should be doable by monitoring the .desktop and .directory files.

> 4.  When the root of the menu is destroyed.  Is this necessary?  Say
> the user deletes all .menu files?  Eh, maybe not useful.

See #1. I'd keep an empty root menu in that case. This would also be
consistent with the beheviour when loading an empty .menu file.

> struct _FrapMenuClass
> {
>     /* ... */
>
>     void (*item_added)(FrapMenu *menu, FrapMenuItem *item);
>     void (*submenu_added)(FrapMenu *menu, FrapMenu *submenu);
>     void (*separator_added)(FrapMenu *menu,
>                             FrapMenuSeparator *separator);
>
>     void (*item_removed)(FrapMenu *menu, FrapMenuItem *item);
>     void (*submenu_removed)(FrapMenu *menu, FrapMenu *submenu);
>     void (*separator_removed)(FrapMenu *menu,
>                               FrapMenuSeparator *separator);
>
>     void (*changed)(FrapMenu *menu);
>
>     /* useful? */
>     void (*destroyed)(FrapMenu *menu);
> };
>
> struct _FrapMenuItemClass
> {
>     /* ... */
>
>     void (*changed)(FrapMenuItem *item);
> };
>
> So we're talking 8 signals - does that make sense?  If you wanted to
> mess around with your class hierarchy, and add something like
> 'FrapMenuElement', of which FrapMenu, FrapMenuItem, and
> FrapMenuSeparator are subclasses, then you could replace all the
> *-added and *-removed signals with 'element-added' and
> 'element-removed' signals, and it would be up to the receiver of the
> signal to do:
>
> void
> my_frap_menu_element_added(FrapMenu *menu,
>                            FrapMenuElement *element,
>                            gpointer user_data)
> {
>     if(FRAP_IS_MENU(element)) {
>
>     } else if(FRAP_IS_MENU_ITEM(element)) {
>
>     } else if(FRAP_IS_MENU_SEPARATOR(element)) {
>
>     }
> }
>
> in the signal handler.  Going this route, you could move a lot of the
> common functions (e.g., frap_menu_get_name(),
> frap_menu_item_get_name(), etc.) into FrapMenuElement.  Anyway, just
> an idea - not sure if it's really worth it or makes all that much
> sense.

I actually never thought about this, but it sounds good to me. Man,
that's going to require some tough refactoring. Give me a night to
sleep over this one.

Thanks for your great input BTW.

  - 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/c70a52bc/attachment.pgp>