Menu-Spec and nested AppDirs #2

[Heinrich Wendel]

Ok, I try to collect proposed solutions and add just another problem. Here the 
test-case again:

While writing a MenuEditor component for pyxdg I ran into the following 
problem. Take the following menu file:

<Menu>
  <Name>Applications</Name>
  <DefaultAppDirs/>
  <DefaultDirectoryDirs/>
  <Menu>
    <Name>Editors</Name>
    <Include>
      <Category>Editors</Category>
    </Include>
  </Menu>
  <Menu>
    <Name>Debian</Name>
    <AppDir>/usr/share/debian/applications</AppDir>
    <Menu>
      <Name>Games</Name>
      <Include>
        <Category>Games</Category>
      </Include>
  </Menu>
</Menu>

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 
AppDir'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 
     editing, though.

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

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.

3) $XDG_CONFIG_HOME/menus/applications:
    This one is for new entries a User does to his menu. This should be part
    of <DefaultAppDirs/>, but would break backwards-compatibility then.

    $XDG_CONFIG_HOME/menus/applications-changed:
    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 :-)