Created attachment 37985 [details] [review]
Proposed patch.

Christian: I just added an applications.menu to ~/.config/menus and it works as
expected...

IIRC, applications-merged is for people distributing software, not for menu editing.

Vincent: You received my tarball? How would you implement proper menu editing
with this? Could you send me a sample file?
I don't think it is a nice idea if a menu editor changes a cruicial
user-editable/-created file.

Oh, note that KDE application.menu has:

        <DefaultMergeDirs/>
        <MergeFile>applications-kmenuedit.menu</MergeFile>

in the end.

Christian: I did not look at it yet and I'm not sure I'll have time to look at
it before tuesday/wednesday.

IMHO, the problem here is that the spec is really not clear when it comes to
menu editing. There are multiple ways to do it...

I did not think a lot about it yet, though (right now I'm trying to fix some
showstoppers).

What do you mean by look at it? Don't you trust my statement how KDE handles it?
I already wrote a mail to xdg list for asking how to do proper menu editing
among multiple menu editors, which obviously involves sharing a common
mergefile. Anyway, ALL of the solutions (except creating a custom
applications.menu and merging the global one into it which is CRACKY) do make it
neccessary to move the merge point to the end of the file.

I meant: "I did not look at your tarball yet".

Christian: please, please give over with the drama. The bug report is now 95% is
now screaming and hand waving and 5% useful information.

Menu editors should edit ~/.config/menus/*.menu - the menu editor will be the
canonical way of editing those files. I don't see the problem here.

Mark: OK, maybe I was too pathetic. Sorry.

I'd really like to see a working sample of how you want menu editing to work.
KDE modifies ~/.config/menus/applications-kmenuedit.menu and merges it into the
main tree after the directory definitions, as I stated above. This is very much
what GNOME Menu Editor does at the moment, except that changes are merged from
~/.config/menus/applications-merged.
Do you want menu editors to create ~/.config/menus/applications.menu, let it
include applications.menu from XDG_CONFIG_DIRS (how would that work?) and put
the changes afterwards?

Note that I still think that 3d-party changes (edited manually or installed by
apps) should be after the directory definitions, not before them.

Yep, creating ~/.config/menus/applications.menu along the lines of:

<!DOCTYPE Menu PUBLIC "-//freedesktop//DTD Menu 1.0//EN"
"http://www.freedesktop.org/standards/menu-spec/1.0/menu.dtd">

<Menu>
  <Name>Applications</Name>
  <MergeFile>/etc/xdg/menus/applications.menu</MergeFile>

  <Menu>
    <Name>Accessories</Name>
    <Exclude>
      <Filename>gcalctool.desktop</Filename>
    </Exclude>
  </Menu>
</Menu>

sounds perfectly fine to me. I understand what KDE does, but I don't really
understand why. It just seems like another unnecessary level of indirection.

Now, there is a problem in that <MergeFile> references an absolute path - so
e.g. if I edit my menus in a GNOME installed in /usr and then start a session
with GNOME installed in /gnome/head/INSTALL, then I still see the menus from
/usr. There was some discussion between Waldo and Havoc on how to fix that a
while back.

Mark: OK, I admit that it would work. [1] points at an xdg thread. If we use a
MergeFile with a fixed name, we'll be fully KDE-backwards compatible. Isn't that
a criterion as well?

[1] http://lists.freedesktop.org/archives/xdg/2005-February/005937.html

It would be nice if KDE and GNOME did the same thing, yes, but that doesn't mean
you blindly follow what KDE is doing - we should at least understand why KDE
can't use ~/.config/menus/application.menu

Okay, I'll close as NOTABUG - it doesn't look like we're going to do what you
supplied the patch for and we don't really need a bug to track the general
"what's the best way to implement menu editing" problem

I'm currently contacting Waldo on this, but apart from that I don't see why we
don't apply this for the sake of consistency; Ignoring menu editing, KDE merges
after the menu definitions. I see NO reason for doing it beforehead and don't
get why don't we adopt the way KDE does merging. From a logical point of view,
why should user changes be merged before menu definitions? Shouldn't we apply
changes after constructing a tree?

KDE doesn't use  
<MergeFile>/etc/xdg/menus/applications.menu</MergeFile>  
because it breaks  $XDG_CONFIG_DIRS: when the admin changes $XDG_CONFIG_DIRS 
that points to a different applications.menu that change will no longer be picked up 
because the location is now hardcoded for this user. 
In KDE we have profiles that we can apply to groups of users. A common usage of this is to 
provide groups of users with an adapted menu. For that to work it is essential that changes 
to $XDG_CONFIG_DIRS are being picked up by all users. 
 
See also http://www.kdedevelopers.org/node/view/876 
and http://lists.freedesktop.org/archives/xdg/2004-July/004227.html 
  

Waldo: I agree this is a problem. But it's really the spec that should be fixed.
I wanted to send a mail about this problem a few weeks ago and never found the
time to do so... Your <MergeFile parent="true" /> proposition looks great for this.

Vincent, Mark: Again, I admit that the way gnome-menu-editor currently acts is
broken. But since the gnome-menus (IMHO) doesn't yet handle the parent attribute
I see no way of handling this in a non-broken way.

Apart from that, I still don't see why merges should happen before the menu
definitions, i.e. why we behave different from KDE in this aspect (cf. [1], grep
for DefaultMergeDirs). We either should change the spec and KDE implementation,
or the GNOME implementation.

[1]
http://webcvs.kde.org/kdelibs/kded/applications.menu?rev=1.26&content-type=text/vnd.viewcvs-markup

<MergeFile type="parent"/> should work fine. Open another bug if not.