Debian Developers - update-menus vs. KDE 3.2

Author

update-menus vs. KDE 3.2

Fabian Franz

2004-04-11, 3:14 pm

Hi,

we at Knoppix Project were not satisfied with the existing update-menus
solution, which just did add a Debian-Menu to the top of the K-Menu.

I have now written a small bash-script, which integrates the Debian-Menu more
nicely into the K-Menu. (attached)

It also "fixes" missing icons (Yes, I'll report bugs against this packages as
soon as possible), adds GenericNames (longtitle menu
field) and localisation of categories.

Run it as root after you have run update-menus in the same dir as
section_icons. (Perhaps this file could be integrated, too)

[ It can be possible that for KDE-CVS packages kdelibs-bin needs to be changed
to kicker ]

Yes, I also know that a hook into update-menus would have been nicer, but this
is future work.

The only thing you need to do after that is to
change /etc/xdg/menus/applications.menu to:

<Menu>
+ <MergeFile>debian-menu.menu</MergeFile>
<Name>KDE</Name>

To actually merge the debian-menu into the K-Menu.

cu

Fabian

PS: Please cc me as I'm not subscribed, yet.

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Christian Perrier

2004-04-11, 3:14 pm

Quoting Fabian Franz (FabianFranz@gmx.de):
> Am Freitag, 9. April 2004 23:11 schrieb Fabian Franz:
>
> And here is the missing attachment ...

Shouldn't this be reported as a wishlist bug against the menu package?

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Mark Howard

2004-04-11, 3:14 pm

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

Bill Allombert

2004-04-11, 3:14 pm

On Sat, Apr 10, 2004 at 08:26:00AM +0200, Christian Perrier wrote:
> Quoting Fabian Franz (FabianFranz@gmx.de):
>
> Shouldn't this be reported as a wishlist bug against the menu package?

No, the way kdelibs-bin handle the Debian menu is the sole
responsibility of the kdelibs-bin maintainers.

Note that the relevant files are conffiles so Knoppix can modify them
to suit its needs.

Cheers,
--
Bill. <ballombe@debian.org>

Imagine a large red swirl here.

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org