Menu Policy - please read if you maintain a package with a .desktop file in it!

[Toshio]

On Thu, 2004-05-13 at 18:04, Seth Nickell wrote:
> 2) If your package is in any of the default package sets:
>   a) You must get approval for any changes that change the menus. This
> includes renaming items or adding new .desktop files. In other words,
> almost any change to a .desktop file, save translations.

If I understand correctly, this scopes to F-Core packages and any
package which updates a F-Core package, not the run of the mill from
F-Extras.  At this stage of the project (Core == Redhat dominated;
Extras == Community driven) that sounds reasonable.  As that changes I
expect issues to arise such as: who is doing the approval?  What are the
criteria for adding menu entries?

>   b) The menu item should usually be the application's
> generic/descriptive name. For example, use "Web Browser" instead of
> "Mozilla" or "Mozilla Web Browser".
> 
I think this is a backwards decision.  I'm much more in need of seeing a
program's given name in order to decide if I want to run it than it's
generic purpose.  Otherwise, what happens if I've selected two or three
web browsers for my machine?  How do I tell which one "Web Browser" maps
to?  If I want to map another browser to that menu item, I would have to
remap the original to its given name in addition to mapping my new web
browser to the "web browser" entry.

(This is different from mapping an entry to invoke the 'Preferred Web
Browser' into the menu.  In that scenario, _I'd_ have selected which one
it was and there would already be another, specific, entry in the menus
for it when I wanted to change it.)

> 3) If your package is NOT in any of the default package sets:
>   a) The menu name should usually be the application's given name + the
> generic/descriptive name. For example, use "Mozilla Web Browser" instead
> of "Web Browser" or "Mozilla".
> 
Reasonable.  But I don't like the way this differs depending on default
package set/non-default package set.  Just use 'Mozilla Web Browser'
whether it's a default or not.

> 3) The default packages in the  package sets (in the comps file) may not
> include any applications that are functional duplicates. In other words,
> if the user clicks all the package sets in the installer (other than
> everything), they should not end up with two web browsers or two
> spreadsheets in the menus. To give a hypothetical example, lets say we
> shipped Gnumeric as one of the default apps in the "Office" package set.
> In this case OpenOffice.org Calc should not show up in the menus, even
> if the openoffice.org package is installed (presuming we install the
> rest of openoffice by default). One way to address this would be to
> include a separate "openoffice.org-calc" package that simply installs
> a .desktop file.

This solution seems to shift the clutter from the menu into the package
manager: Instead of an extra entry for OOo Calc in the menu we have an
extra package in the system.

As an alternative I propose giving per user menu editing the following
features:

1) 'Defaults view'/'All view' preference toggle on the menus that either
shows the entries redhat has decided are reasonable defaulted on or all
.desktop entries.

2) User is easily able to set entries to be shown in (their private)
Default view from now on.

>   a) Exception: Although KDE and GNOME overlap we include both in
> package sets. To deal with this, we mark smaller utilities and core
> desktop pieces that overlap (e.g. gnome-utils, kdeutils, kdebase,
> kdemultimedia, gnome-media, kdeadmin, etc) with "OnlyShowIn=...". That
> way we still don't get overlapping menu items. By default all items in
> these sort of packages should be marked OnlyShowIn. Ask me about
> specific things you think should be exceptions.
> 
When handling the 'All view' menu preference proposed above, I think we
need to disregard 'OnlyShowIn.'  This allows a user to display tools for
environments other than their own if they want to cherry-pick the one
that is best suited to their needs.

> Some general guidelines:
> 
> - Include a generic version of the name, even if your app isn't install
> by default (e.g. "Mozilla Web Browser").
Reasonable

> - Don't add menu entries for things for the heck of it. For example, the
> number of people who launch emacs from the menus is probably very
> small. ;-) If its mostly launched from the command line (could still be
> an X application, note), don't put it in the menus.
> - Don't add a bunch of entries for the same application unless its a
> really big monster application (like OpenOffice.org). For example,
> KBabel, a translation tool has three menu entries. It shouldn't!
> - Don't have a "_____ Configuration" menu entry (e.g. Chromium
> Configuration). Configuration should be launched from inside the app. If
> its not, cry, but don't add it to the menus ;-)

These guidelines remind me of the following Elliot Lee .signature circa
1997:
  What`s nice about GUI is that you see what you manipulate. 
  What`s bad about GUI is that you can only manipulate what you see. 

The menu provides a GUI to help you find the program you want to run. 
It may not be able to do that very effectively with five hundred web
browsers displayed but it _certainly_can't_ if there's no way to display
the program you want at all.

Unless I misunderstand how menus are generated, a policy that disallows
certain .desktop in the distribution will cause this kind of problem. 
Instead, the .desktops should be installed in the system but contain
information on whether they should _by_default_ be displayed.  That way
it's possible to create GUI'd methods to add or subtract the additional
programs from the menus.

-Toshio
-- 
_______S________U________B________L________I________M________E_______
  t  o  s  h  i  o  +  t  i  k  i  -  l  o  u  n  g  e  .  c  o  m
                                                          GA->ME 1999
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20040516/c21e9ad1/attachment.sig>