XDG menu implementation

[Jannis Pohlmann]

On Thu, 27 Jul 2006 11:33:21 +0200, Benedikt Meurer wrote:

> Jannis Pohlmann wrote:
> > I. The "egg" thing
> > 
> >   We talked about a testing library similar to GNOMEs libegg about
> > ten days ago. We agreed that something like this might be useful
> > but two questions remain: How do we name it (libeasterbunny would
> > be funny, I'd prefer something else, though) and who will add it
> > to /trunk?
> > 
> >   As I'll probably be the first to add a project to this "libegg"
> > copy, I hereby offer to create and maintain it (once we agreed on a
> > name).
> 
> As Brian suggested, libfrap, simply because of
> FrapMenu/FrapMenuItem. ;-)

Hehe, ok. I like the coffee idea in general, so libfrap is perfectly
fine.

> > II. The menu API
> > 
> >   Before I started working on the implementation, I talked to Benny
> > and he suggested looking into gnome-menus (libmenu) and take the
> > best out of it. What I found was a real mess - it's far from being
> > clean and the API is a kind of weird DOM-like tree structure and
> > it's very unhandy for client programs/libarries to use.
> > 
> >   I browsed through their code a few days, also read the
> >   specification carefull and was finally able to create a GObject
> >   class hierarchy concept:
> > 
> >   The most important classes are (and will be): 
> > 
> >     XfceMenu - represents a menu defined in a <Menu> element, with
> > all submenus, a menu directory, a set of include/exclude
> >                rules etc.
> > 
> >     XfceMenuDirectory - basically represents the menu directory
> > desktop entry containing a localized name, an icon and
> >                         a description for a XfceMenu object.
> > 
> >     XfceMenuItem - an application desktop entry which may appear
> > below multiple XfceMenu objects. Contains information
> >                    about the application icon, command, name,
> >                    description etc.
> > 
> >   Internally, some other classes like e.g. XfceMenuMatchRules (for
> >   <Include>/<Exclude> elements) will be used as well as some kind of
> >   monitoring system (probably Gamin).
> > 
> >   The API for those classes is simple and comes straight to the
> > point. Here's an example taken from the XfceMenu class:
> > 
> >    XfceMenu *xfce_menu_get_root (void);
> >    
> >    const gchar *xfce_menu_get_filename (XfceMenu *menu); 
> >    void xfce_menu_set_filename (XfceMenu *menu, const gchar
> > *filename); 
> > 
> >    const gchar *xfce_menu_get_name (XfceMenu *menu); 
> >    void xfce_menu_set_name (XfceMenu *menu, const gchar *name);
> > 
> >    XfceMenuDirectory *xfce_menu_get_directory (XfceMenu *menu);
> >    void xfce_menu_set_directory (XfceMenu *menu, 
> >                                  XfceMenuDirectory *directory);
> 
> Concerning the API, Thunar (and the possible application browser) adds
> some requiresments here:
> 
>  a) It should be thread-aware (not necessarily thread-safe). That is
> queries on the tree must be possible from various threads (not
> necessarily on the same XfceMenu/Frap, as that would probably add too
> much locking overhead).

Yes, that's something I didn't care about until now. But it should be
doable. Perhaps you can point me to some thread-safe library code where
I can get inspirations from? That would be cool, as I still only have a
vague image of how this needs to look like.

>  b) Thunar (currently the "Open With" dialog) needs a way to query all
> installed applications (-> .desktop files) that claim to handle
> atleast one MimeType (the condition can be checked in Thunar, once we
> have the application list). Currently, there's no clean way to
> retrieve this list and structure it according to the menu definition.
> This will also be needed for the application browser.

Of course, something like this will be implemented. All XfceMenuItems
(which represent application desktop entries) will be stored in a kind
of cache (database, DesktopFile-Id hash table) and it shouldn't be hard
to add mime query functions for this.

> Besides that:
> 
>  c) The library should not depend on anything except libxfce4util and
> gobject (well and Gamin/FAM of course). If you plan to add convenience
> functions for the menu creation (which would certainly be nice), add
> them to a separate .so file.

Yep, I only plan to depend on libxfce4util, gobject and Gamin/FAM.
Any GUI related stuff may be put into a separate library.
 
> > III. Implementation details and status
> > 
> >   Internally, it's all about GObject classes and communication
> > between them. We'll also need some kind of file and directory
> > monitoring, maybe we can take ThunarVfsMonitor as a reference here.
> 
> Just use FAM/Gamin here (optionally). The usage is simple and Gamin
> offers backends for various native monitoring frameworks.

Agreed.

> > Please tell me what you think about it - does the concept sound ok
> > to you? Personally, I really like it and I think it's a good
> > starting point.
> 
> Definitely.

Fine.

Regards,
Jannis