Re: [Usability] any menu editor suggestions?

[Christian Neumair <chris gnome-de org>]

Am Freitag, den 25.03.2005, 17:46 -0500 schrieb Seth Nickell:
> > Note that things changed meanwhile: I've made pretty good progress at
> > improving gnome-menu-editor. It displays application and menu icons, one
> > can add menus and applications and copy apps between various menus. I've
> 
> We shouldn't have the feature of moving items between menus.Allowing
> creation of new menus and allowing new launcher items to be created
> there (or existing launchers to be copied),

Indeed, this is actually the current implementation. You drag an app to
an unselected menu and it will be shown in there, in addition to the
current menu. You can then use the "Display" column to hide the entry
from the current menu. If you mess it all up, you can still press
"Default" and get a tidied-up menu.

> as long as the names were
> tagged such that they'd never be confused with "upstream" menus (that
> is, if we later add a menu item they won't have merge issues).
> [...]
> just make sure that the "auto created" entries can't get
> confused with future .desktop files. For example, you should probably
> prefix the file names with something
> "userdefined-gedit-3829798.desktop" or whatever.

Thanks for pointing out this very interesting issue I've not paid
attention to at all. I'll make sure that these filenames are unique.

> As a minor quibble, I would disable allowing multiple selection in the
> left hand menu. Its not really necessary, and it could be confusing.

I've actually spent much time modelling and organizing this cracky
filtering stuff. Although it means some headache for the coder, I still
found it *very* convinient to list all desktop files if I just had known
the name of an app without any context ("let's hide xine, no matter
where it is located"). Is that worth an additional function/button, like
having a list of all apps with some widgets to manipulate in which of
the menus they are contained in they are shown? I'd like to get Calum's
feedback on this, because as far as I can see, this multiple menu
selection stuff was an intrinsic part of his initial proposal.
He initially also wanted some layout reordering magic. But I'm not
really eager to mess around with these <Layout/> and <DefaultLayout/>
nodes taken that whoever invented them thought it would be a good idea
to sort menus between menu items, like

<Layout>
  <Menuname "ZMenu"/>
  <Filename "totem.desktop"/>
  <Menuname "Eekmenu"/>
  <Separator/>
  <Filename "gnumeric.desktop"/>
</Layout>

I bet we'll mess up this fragile layout stuff at some point when doing
too much reordering. Also this clashes with the UI of the menu editor,
since we totally separate menu from menu items. But won't user complain
if they get a layout they can't change now that gnome-menus HEAD
supports layout?

> Lets keep this thing dead simple and focus on making sure it never
> breaks (no matter how the desktop/distro upgrades the system vfolder
> definitions, what apps get installed / uninstalled, etc).

This is unfortunately impossible - at least when it comes to backwards
compatibility. Waldo Bastian recently changed name of the toplevel menu
from (the formerly inconsistent) "KDE" to "Applications" for the
applications.menu shipped with kde-libs [*], which means that old KDE
versions will definitly break, since we currently force the toplevel
node to be called "Applications" on creation. Also, the layout shipped
with gnome-menus doesn't merge kmenuedit.menu, which contains the menu
modifications from KDE ATM; we plan to share
~/.config/menus/applications.menu as menu editor's playground at some
point, though. As you can see, there are still many hurdles for real
compatibility, its not all about specs :/.

[*] which remembers me of ranting that there is no
freedesktop.org-managed menu package with translated menus that can be
used as a base for all desktop environments.

-- 
Christian Neumair <chris gnome-de org>