menu spec: [menu-file-basename]-merged directory

Matt Kynaston mattkyn at gmail.com
Thu Mar 17 18:23:34 EET 2005


Thanks.Waldo

> It allows third parties to install extensions to the menu.

You mean like a submenu? Gotcha. Don't know how I missed that :|

Doesn't solve my initial problem, though... Apologies if what follows is long.

As a workaround, I've tried to create a
~/.config/menus/applications.menu that contains just:
      <!DOCTYPE Menu PUBLIC "-//freedesktop//DTD Menu 1.0//EN"
        "http://www.freedesktop.org/standards/menu-spec/1.0/menu.dtd">
       <Menu>
         <Name>Applications</Name>
         <MergeFile>/etc/xdg/menus/applications.menu</MergeFile>
         <MergeFile>menu-editor.menu</MergeFile>
       </Menu>

Interestingly, both gnome-menus and pyxdg's (and I suspect KDE's)
implementation here is broken - according to the specs: "If the
filename given as a <MergeFile> is not an absolute path, it should be
located relative to the location of the menu file being parsed." Yet
neither work properly unless menu-editor.menu is in my
applications-merged dir - which means also means it gets merged twice
:(

So to comply with the specs and still be functional, I changed it to:

<!DOCTYPE Menu PUBLIC "-//freedesktop//DTD Menu 1.0//EN"
 "http://www.freedesktop.org/standards/menu-spec/1.0/menu.dtd">
<Menu>
  <Name>Applications</Name>
  <MergeFile>/etc/xdg/menus/applications.menu</MergeFile>
  <Menu>
    <Name>System</Name>
    <Exclude>
        <Filename>gdmflexiserver-xnest.desktop</Filename>
    </Exclude>
  </Menu>
</Menu> 

This is still broken in Gnome (System menu appears twice), but I
actually think it's far more intuitive if a menu editor edits a 'main'
menu file rather than appending its changes to a long list of others.
If the specs said this was how menu editor should work, it would solve
the "duelling menu editor" problem without any other changes.

What do people think?

Matt



More information about the xdg mailing list