Menu-Spec and nested AppDirs #2

[Heinrich Wendel]

On Tuesday 07 June 2005 05:55, Havoc Pennington wrote:
> 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.

Yes, this could be done. I just thought we might cmoe up with a more elegant 
solution.

> 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?

There are two options if it's in the user's homedir:

1.) The User added a new menu entry. A menu editor might give the option to 
delete new entries the user has made.
2.) The User edited an existing systemwide entry. A menu editor might give the 
option to revert those to the original values.

The following two problems arise:

1.) A legacy menu was inserted that has a .directory entry. Now you want to 
edit the .directory entry. In order to do that the menu editor has to create 
a new .directory entry, because the old one has the name ".directory" and 
this might conflict with other legacy entries. This entry will be marked as 
"new" then, because there is no other one with the same desktop-file-id. But 
in fact it should be marked as "edited", so it is revertable.

2.) A menu in the system wide applications.menu has no .directory Entry for 
one menu. The menu editor then creates one and this one is marked as "new" 
again instead of "edited".

> Essentially a smart enough menu editor should be able to solve these
> problems, right?
>
> Havoc
mfg, heinrich :-)