XDG menu implementation
info at sten-net.de
Thu Jul 27 12:13:35 CEST 2006
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
> > 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.
> > 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.
More information about the Xfce4-dev