Menu-Spec and nested AppDirs #2
h_wendel at cojobo.net
Mon Jun 6 19:50:04 EEST 2005
Ok, I try to collect proposed solutions and add just another problem. Here the
While writing a MenuEditor component for pyxdg I ran into the following
problem. Take the following menu file:
This works fine as long as you don't try to edit things.
1.) try to edit an entry in the "Games" menu, but what happens? You can't edit
it because /usr/share/debian/applications will have a higher priority than
the users settings.
2.) try to move an entry in the "Games" menu by excluding it in the debian
menu and includnig it in the "Editors" menu, but what happens? It won't work,
because the "Editors" menu can't find the item, because it don't
has /usr/share/debian/applications in it's AppDir's.
3.) try to move the whole "Games" menu to a toplevel menu, but what happens?
It will be empty, because it don't has /usr/sharedebian/applications in it's
4.) Try to detect if an entry was edited by an user, is a system-wide entry or
a new entry created by a user. This is very difficult with the current
situation. E.g. take a menu which previously had no .directory entry, this is
not a new menu, but an edited menu, but how to detect that?
Everything said applies to AppDirs and DirectoryDirs in the same way.
Now to the proposed solutions:
1) Use a separate directory for edited .desktop files because if
$XDG_DATA_HOME is "/usr/share in your homedir", I think its just
as inappropriate to put edited files there as it would be to put
them in /usr/share.
This is really something that should be discussed as "what exactly
is $XDG_DATA_HOME for?", rather than just thinking about menu
This sounds good, and might be used to fix issue 4.
2) That you give edited files a different desktop file ID so that you
no longer have to worry about the order of <AppDir>s in the .menu
file when you're implementing a menu editor which
modifies .desktop files.
I think this makes sense for various reasons, but to give one
example - consider a .desktop file which is <Include>d in two
menus. If a user edits an entry in one menu, she wouldn't also
expect it to change in the other menu. (Yes, its a corner case
That would fix issues 1,2,3.The problem with that approach is that the
relation between original and renamed file is lost, in particular
applications or settings that refer to the original .desktop file will fail
to pick up the changes that the user has made. It would make the whole
concept of the desktop file ID useless.
This one is for new entries a User does to his menu. This should be part
of <DefaultAppDirs/>, but would break backwards-compatibility then.
This one is for changed entries. Menu Editors have to add it to the Menu
if they made a change.
This one would fix issue 1 and 4, but not 2 and 3.
4.) We only have a global pool of AppDirs/DirectoryDirs, not a local one for
every menu. AppDirs/DirectoryDirs in Submenus are added at the end
of that global pool, so they have priority. To prevent collisions the
AppDirs/DirectoryDirs might have a prefix attribute. Additionally
AppDirs/DirectoryDirs that are in the user's folder always have priority
instead of the system-wide dirs.
This would fix issues 1, 2 and 3, but not 4. It was pointed out, that this
might break other things, not foreseeable yet.
Any other ideas?
mfg, heinrich :-)
More information about the xdg