Menu-Spec and nested AppDirs

[Mark McLoughlin]

On Mon, 2005-06-06 at 17:03 +0200, Waldo Bastian wrote:
> On Thursday 26 May 2005 18:05, Mark McLoughlin wrote:
> >
> >   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 ....)
> >
> >      Anyway, its this ".desktop file renaming" part of my suggestion
> >      which is really more relevant to the problem you're pointing out.
> 
> 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.

	I guess it depends on the menu editor. If you renamed an item in
GNOME's menu editor, I think you'd only expect the change to be visible
in the menus. But I can see how other menu editors might expose the
concept of editing application's desktop entries.

	Anyway, my main reasoning for suggesting that we do it this way was
that if you installed an application in your homedir, you'd expect the
app to install the .desktop file in ~/.local/applications ... but the
more I think about it, that's probably pure folly and not what
$XDG_DATA_HOME is intended for at all. $XDG_DATA_HOME should probably
always be user created files.

Cheers,
Mark.