menu editing with multiple menu editors

[Waldo Bastian]

On Sunday 27 February 2005 11:37, Christian Neumair wrote:
> I've just finished writing a prelimitary version of a GNOME menu editor
> that simply does some <Include>/<Exclude> magic to adapt the application
> menus in $XDG_CONFIG_HOME without providing any sophisticated layout
> manipulation magic. To be more precise, I place my modifications in
> $XDG_CONFIG_HOME/menus/applications-merged/gnome-menu-editor.menu. The
> KDE-specific applications.menu contains
>
>         <DefaultMergeDirs/>
>         <MergeFile>applications-kmenuedit.menu</MergeFile>
>
> in the end. Therefore, the kmenuedit changes always override other
> changes from <DefaultMergeDirs/>, even those from applications-merged.

Yes, that is intentional, since I assume that applications could install 
extensions into applications-merged and the user should be able to edit such 
extensions with the menu-editor. I have considered using applications-merged 
instead but the problem with that is that I don't think that there is a 
defined order for the .menu files in there, and I'm afraid that that will 
lead to spurious problems where changes made with the menu-editor will not 
"stick" in some situations. (regardless, I still get quite a few bugreports 
about such problems, and it's quite hard to get a good understanding what is 
causing a specific problem since there is quite a lot of interaction going on 
between a bunch of files)

> How can we aviod that the changes of one editor don't take effect in the
> menu because they are overriden my changes of another editor?

I think the easiest solution would be to use a single file for storing the 
changes in, we could be using applications-kmenuedit.menu for that. If there 
is objection to that name it would be possible to migrate to a more neutral 
name, although that always tends to cause some inconvenience for the end 
user. E.g. we could use 'application-menuedit.menu' instead and let 
'application-kmenuedit.menu' include that one for backwards compatibility.

> Distributors will have to decide what menu file they use, so the problem
> could exist the other way around as well.

Not sure if I understand, but I expect distributions to make their distro 
specific changes to applications.menu. Not to any of the menu-edit files.

> Wouldn't it be useful to have a shared menu file? 

Yes.

> How do you organize 
> changes to that file? I currently use a simple libxml2-wrapper to get
> existing menu nodes or construct them if they're not yet there and
> append an <Include> or <Exclude> rule set for the shown/hidden menu
> entry, deleting all former rule sets matching the <Filename> of the
> desktop file in question in the menu.

Yes, that's what kmenuedit does as well.

> From what I can see from screenshots, KMenuEdit is way more
> sophisticated (and way more complicated). How can we avoid messing up
> your complex layout, still being able to edit a common menu file?

kmenuedit records the actual layout in the <Layout> tag. If you just leave 
those tags alone everything should be fine.

kmenuedit also generates <Move> tags if you menus around, but those shouldn't 
cause problems if you just leave them around.

The approach that kmenuedit takes for editing is that it presents the menus 
based on the normal menu-layout code, it then generates "changes" in the form 
of "remove application X from menu Y", "add application Z to menu W". And it 
then basically adds <Menu><Name>W</Name><Include>Z</Include></Menu>
to applications-kmenuedit.menu. It's slightly smarter than that, in the sense 
that it will reuse existing Menu nodes instead of creating new ones for each 
changes. And it will throw out previous <Include>/<Exclude> rules for the 
same file. So kmenuedit itself doesn't really do a whole lot of parsing of 
applications-kmenuedit.menu, so I don't expect it to break if someone else is 
making changes in that file.

To reduce the room for errors, I think it's important to make sure that the 
file always contains at most one <Menu> entry for a single menu. And you seem 
to be doing that already :-)

Cheers,
Waldo
-- 
bastian at kde.org   |   Free Novell Linux Desktop 9 Evaluation Download
bastian at suse.com  |   http://www.novell.com/products/desktop/eval.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xdg/attachments/20050227/0b2309ad/attachment.pgp