hp at redhat.com
Mon May 12 22:51:30 EEST 2003
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:
First, some cases and descriptions of how they should work.
File foo.desktop should move from directory A/ to directory B/
while retaining the basename foo.desktop and the same contents.
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
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
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.
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:
In the <Menu> for Applications/Games do an
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
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.
More information about the xdg