Skip to main content

Freedesktop Menu support

No replies

I've been working on a plan for switching from our current menu system
to the Freedesktop menu specification, and i'd like to share the
thoughts i've had so far on the matter. Please note, i'm still at the
_very_ earliest stages of working through this, and would love to hear
any ideas/feedback/complaints/etc that anyone has on the topic. (And
please bear with me if this gets a bit lengthy. :) )

Currently, our menu system uses events (generated from the *.cfg
files) to define and construct the menu groups and items. Each menu
group must be explicitly declared, as well as the other groups which
it links to or from. The biggest problem with this, is that a broken
or incorrectly configured link can cause the group (and all items
contained within) to not be loaded and attached, and items which
declare themselves to be in a group that does not exist will be
created, but will never be available. In addition, although the *.cfg
files tie in nicely with the event system, they become more and more
verbose and more difficult to edit by hand as the menu grows.

The other major issue that has come up with the menu is the lack of
support for user-customization. We currently have a single config file
for the menu structure, groups, and some default items
(startmenu.cfg), and each application has a cfg file describing its
config, and the group in which it belongs. In order to customize the
menu, each user must find and edit these files on their local copy.
This is one matter for developers familiar with the system, but it is
probably out of the question to expect end users to dig for and edit
these files (especially as there is currently no way to do this

In researching the menu specification (and the approaches that other
desktops have taken with it), i've come up with a list of five main
changes which i think would be best to start with:

1) Switch to the Freedesktop desktop-entry file format for describing
applications (and other more general 'desktop items'). This would
provide a more generic method for describing applications, rather than
the menu- or toolbar-specific descriptors that we have been using to
date. The main changes associated with this involve the way the config
files are found/loaded (currently in ConfigControl), and the manner in
which applications are executed.

2) Use the Freedesktop standard, registered menu categories. Although
changing the names of the menu groups is a small change in and of
itself, i would like to also switch to generating the categories
on-the-fly, based on the items found and the way the user configures
the menu (rather than the static construction we use now). Most of the
necessary modifications for this are local to the menu codebase.

3) Switch to the Freedesktop menu file format. This is an xml file
format that leans more towards providing 'instructions' for generating
the menu tree, rather than directly specifying the structure. The
format of the file is much simpler and more intuitive (or at least
more domain specifc) than the java-xml serialization files that we
currently use, which will assist with the 'hand-editing' issue until
we develop a graphical config system. I think the best thing we stand
to gain from this change is making lg3d 'drop-in' compatible with
other desktops which use the specification (notably KDE, Gnome and

4) Implement 'menu merging'. Although this is really an integral part
of the menu file format, i wanted to address it separately as it's the
most significant change from our current approach. The basic idea is
to have multiple menu files (system menus, user-defined menus, partial
menus) parsed and merged into a single final menu. This is merging is
performed in a specific, top-down manner, allowing users to customize
and alter the menu to their liking, without having to dig for and hack
up the default system files.

5) Switch to using the Freedesktop standard file locations for the
menu/desktop-entry config files. This will assist in making the lg3d
menu interoperable with other desktops, as well as allowing lg3d (and
users) to make use to the menu/desktop-entry config files an existing
desktop. This will require some changes in where lg3d goes looking for
files, as well as how those files are loaded and conveyed to the
interested portions of the system.

Whew! :) I think that about sums up what i've come up with so far.
Once again, i'm perfectly flexible on all this, and would really value
any one's input or ideas.

If you're interested in the details of the spec, here are some links
for convenience:

Desktop Entry spec:
Menu spec:
Desktop Base Directory spec (standard file locations):

- Colin

To unsubscribe, e-mail:
For additional commands, e-mail: