[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: update-menus vs. KDE 3.2



On Sat, Apr 10, 2004 at 08:26:00AM +0200, Christian Perrier wrote:
> Shouldn't this be reported as a wishlist bug against the menu package?

No, it needs discussion first. I'm not a kde user, but I think their
menus have changed in the past from an integrated one to having the
debian menu separate - A simple patch like this is unlikely to prove a
long lasting solution.

A typical desktop Debian installation has lots of applications
installed. These include apps based on kde, gnome, motif and others.
They are installed on the system, so the user is likely to want to use
them all at some point. At the moment, most menus have the main section
generated by .desktop files and then the Debian section in some hard to
reach submenu at the end of the menu. This is understandable - the
.desktop files offer far superior quality to Debian menu entries
(including translations and having support from upstream); and
applications targeted towards a distribution should appear more
prominently than other random applications.

A use case example of current use of the menu: trying to find a graphics
application to create a diagram to go in my dissertation.

(I'm using gnome. Applies similarly to other desktops)
User clicks on gnome applications menu 
Graphics menu looks promising (even has a nice icon), so clicks on it.
There are a lot of items in the menu. No further sub-categorisation
means that it includes icon editors, photo collection programs, basic
drawing programs and technical drawing programs all in one long list.
This takes a long time to go through - hover over each item, read
descriptions in tooltips, try a few apps and find they're not suitable. 

Then the newbie user probably thinks that they don't have any suitable
app installed. A friend points them to the debian menu. 

Goes to applications->debian->Apps
(I have menu hinting optimisation switched on)
Sees a few apps, many without icons, none with tooltips. Thinks that
Gnome menu is good, but Debian developers don't care about their menu
and don't do a good job. Thinks about how nice their menu at work is
(which was custom designed for a smaller set of applications). 
Doesn't know what most of the apps are. Menu reasonably short, so not
too much effort to look through.
Sees Graphics submenu. Looks promising so clicks on it. Again, a short
menu. Clicks on Vector submenu and finds a few applications. Has to try
them all since they don't have descriptions, but finds suitable
application (xfig, of course). 


Now, what in an ideal world should happen (IMHO):
User clicks whatever looks more likely to contain what they want:
application->Graphics->Vector. Sees all apps, with icons and tooltips in
their local language. Applications for that desktop are at the top of
the menu. Other applications are either at the end of the menu below a
separator if the menu is short, or in a submenu if the menu is already
quite long. All menus are of reasonable length. 

How to make this happen:

- Menu package has to interpret both .desktop files and current Debian
  menu files. Trying to use only our own menu files is hopeless -
  upstream developers are the only people who can do a good job of this.
  Their translators translate the application and also the menu files. 
  Also, why should we write menu entries when upstream have already done
  this. We can't even share our changes with upstream since nobody else
  uses them. 
- Indicate which desktop each application is targeted to. Either by the
  use of a hint in the Debian menu file (e.g. GNOME), or by the location
  in which the .desktop file was found.
- Turn on hint optimisation by default
- Generate all menus entirely with the menu package. Menus with hints
  for that desktop will always go at the top of the menu. Other items
  will go either at the end of the menu or in a (non-gnome/other/?)
  submenu. 
- Document standard hints to use in debian menu entries. Make it easy
  for people to add new ones to this document. Have these in the menu
  package with translations. 
- possibly: Remove the section entry from the Debian menu files. Use
  only hints.  This may make it easier to merge the debian menu into the
  current upstream menu categories. 


- File lots of bugs against packages which have bad menu entries. Bad
  means menu entries which don't have hints, or use hints which are
  different to what other apps use. For example, my editors menu has two
  submenus, one called "Word processors" and another "WordProcessors".
  They should be the same. There are also lots of items in the editors
  menu that don't have hints, so that menu is unnecessarily long. 
  Developers can choose to use either Debian menu format or .desktop
  format. Looking through my debian menu, almost all graphical
  applications would need bugs filing. 

The last point is the most important and probably the one which has led
to the Debian menu being so underused at the moment. If you decide to
make these changes, the menus will be in a terrible condition until many
packages get their menu entries into shape. There's nothing we can do
about that other than filing bugs and waiting. 

-- 
  .''`. Mark Howard
 : :' :
 `. `'  http://www.tildemh.com 
   `-   mh@debian.org | mh@tildemh.com | mh344@cam.ac.uk 

Attachment: signature.asc
Description: Digital signature


Reply to: