XDG menu implementation

Jannis Pohlmann info at sten-net.de
Thu Jul 27 04:15:17 CEST 2006

Hi all,

some might have noticed it: I've started to work on the XDG menu
implementation I was talking about when we discussed Google's SoC.

I'd like to discuss several topics in this mail:

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

  While I'm at it, how do we want to name the XDG menu implementation?
  Should it be a more fresh name like "exo" or is "libxfce4menu" ok?

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

  As you can see, it's a typical GObject API with property notify
  signals etc. It's very easy to use. For a usage example, see


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.

  lists detailled information about the current implementation status of
  what I called "libxfce4menu" for now. Besides monitoring, the main
  parts missing are menu file merging, menu layouts and the desktop
  entry database.

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


More information about the Xfce4-dev mailing list