menu editing

[Havoc Pennington]

Hi,

I started implementing menu editing, and of course immediately
understood better what problems Waldo was seeing. ;-) I'm trying to
think through the editing problem, not sure I have it figured out yet,
but I want to post some thoughts and see if anyone has feedback.

I'm assuming that the menus are exported as a "filesystem" 
which looks something like:

 Applications/
   Games/
    solitaire.desktop
    tetris-clone.desktop
   Office/ 
    wordprocessor.desktop

etc.        

First, some cases and descriptions of how they should work.

    Move file
    ===

     File foo.desktop should move from directory A/ to directory B/
     while retaining the basename foo.desktop and the same contents.

    Copy file
    ===

     File foo.desktop's contents should be transferred to some other 
     name. If the other name happens to be bar.desktop, and a file 
     bar.desktop exists in another directory than the copy destination, 
     bar.desktop in that other directory should not be affected.
     If bar.desktop exists in the copy destination it should be 
     replaced.

    Delete file
    ===

     File foo.desktop should vanish in the directory where it was 
     deleted, but not elsewhere.

    Modify file contents
    ===

     File foo.desktop should change contents while retaining the name 
     foo.desktop. Other files in different locations, even if they 
     are named foo.desktop, should not change contents; unless 
     they appear as 'hard links' in the VFS.

     Note that renaming a menu item is done by modifying file contents. 

OK, so various obvious approaches to this break as soon as non-system
.desktop files are created. If you only have system .desktop files and
move those around it works fine. 

However, if the user edits /usr/share/applications/foo.desktop, you can:

 a) create a ~/.local/share/applications/foo.desktop and modify that
or
 b) create ~/.local/share/applications/foo-XXXXX.desktop and modify that

a) breaks because it changes foo.desktop in places other than the
immediate place where the user was editing; i.e. all files with
"foo.desktop" as basename appear to be hardlinks to one another.

b) breaks because it changes the file's name when you modify its
contents. yay semantic guarantees! VFS users will have fun with this.

You can kind of live with a) without breaking UNIX semantics if you
VFS actually claims that all foo.desktop are hard links to each
other. However, the same breakage arises if you copy foo.desktop to
bar.desktop and bar.desktop happens to exist; only hard links can't
paper over the breakage in this corner case.

Or in other words, the hard links trick falls over as soon as you have
one foo.desktop with different contents from another foo.desktop.

Hard links seems a bit sucky anyway; I consider them a bug in UNIX
filesystem design and nobody wants to deal with them anyhow.

Hrm.

So, possible solution, see if this will work. We might take the basic
problem to be that ~/.local/share/applications breaks the clean
recursive nature of the menu tree; i.e. changing one submenu affects
other parts of the tree. So we could try fixing that:

 - Reserve ~/.local/share/applications as a place to install .desktop
   files when you're building apps in your homedir. i.e. it's not 
   edited by the VFS.

 - When editing with the VFS, for each Applications/Games/ or whatever 
   directory that is edited, create: 
    ~/.local/share/something/Applications/Games/*.desktop

   In the <Menu> for Applications/Games do an
   <AppDir>~/.local/share/something/Applications/Games</AppDir>

   The implication is that you can create
   ~/.local/share/something/Applications/Games/foo.desktop which overrides
   foo.desktop only inside Applications/Games with no global
   implications.

Does that work?

Presumably a systemwide equivalent would exist also.

The datadir/something/* would be used only for menus, not
for mime types or anything of that nature. For MIME, 
you still edit the master copy of the application's .desktop file 
in the main applications/ directory.

As an aside - we should probably allow and expand "~" in the .menu
file, because you don't want to hardcode path to homedir in a homedir
that may be nfs-mounted in different places.

Havoc