Menu-Spec and nested AppDirs #2

[Havoc Pennington]

On Mon, 2005-06-06 at 18:50 +0200, Heinrich Wendel wrote:
> 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 isn't specified clearly enough for me - I'm not sure I understand
it.

> This would fix issues 1, 2 and 3, but not 4. It was pointed out, that this 
> might break other things, not foreseeable yet.

The reason we used clean recursion is to preserve modularity. So for
example we might have upstream GNOME menus, and then Debian adds a
submenu, and Codeweavers adds a submenu, and someone else adds a
submenu; on Windows every single app seems to add a submenu.

The goal is to keep every submenu standalone. You don't want the XML
elements in one submenu to have any chance of affecting the global menu
or other submenus.

Some thoughts on the problems you mentioned:

1) I think the goal of a solution here should be to get a
user-modifiable directory in front of /usr/share/debian/applications. I
can imagine various spec features to support this, but a low-tech
solution is just to insert another <AppDir> for a user-modifiable
directory, when the menu is edited.

2) I think the menu editor could solve this.

The simple approach is to ensure that the 
origin <AppDir> of an entry is always added to the destination menu 
when doing a copy. Or that the destination is included by absolute path.

Both have somewhat strange side effects, but these could be avoided by
making the <AppDir> specific to the destination menu item rather than
the entire destination menu. This can be done with the existing spec by 
creating an "inline" menu that contains only the new menu item.

A more elegant but semantically equivalent solution might be useful.


3) The menu editor could just keep <AppDir> with the games menu.

4) I don't think I understand this one. If it's in the user's homedir
then it was edited, if it's systemwide then it's systemwide, right?


Essentially a smart enough menu editor should be able to solve these
problems, right?

Havoc