XDG menu implementation

[Benedikt Meurer]

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. ;-)

> 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).

 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.

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.

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

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

> Regards,
> Jannis

Benedikt