menu editing with multiple menu editors
bastian at kde.org
Sun Feb 27 16:16:22 EET 2005
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
> 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?
> 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 :-)
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
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xdg/attachments/20050227/0b2309ad/attachment.pgp
More information about the xdg