[RFC] Fixing the Desktop Menu Specification.

[Vincent Untz]

Le jeudi 10 novembre 2011, à 16:58 +0000, Peter Brett a écrit :
> Vincent Untz <vuntz at gnome.org> writes:
> 
> > Le mercredi 09 novembre 2011, à 16:54 +0000, Peter Brett a écrit :
> >> 
> >> * Add some language that requires desktop environments to display
> >>   .desktop files that don't include a Main Category but that would
> >>   otherwise be displayed. (Does that make sense?)
> >
> > One issue here is that you're assuming a .menu file will always display
> > main categories at the toplevel. Which is not necessarily true.
> 
> Isn't it?  The spec currently states:
> 
>   The list of Main Categories consist of those categories that every
>   conforming desktop environment MUST support. By including one of these
>   categories in an application's desktop entry file the application will
>   be ensured that it will show up in a section of the application menu
>   dedicated to this category.
> 
> That seems to contradict you...

It will appear somewhere, not necessarily at the toplevel.

> > What we can easily do, though, is have some text requesting implementors
> > of .menu files to have a "catch-all" submenu ("Other" in GNOME) where
> > apps that don't fit anywhere else would go.
> 
> Yes, that would be a good idea.

Cool, let's do that.

> >> I think the problem is that, at the moment, the Main Categories are
> >> assumed by the specification to form a complete ontology, but they
> >> don't.
> >> 
> >> Here's an idea: instead of having separate Main Categories and
> >> Additional Categories, why not simply have a list of Suggested
> >> Categories and a recommended algorithm for determining which ones to
> >> display, based on frequency of occurrence?  Is that plausible?
> >
> > This means adding icons, translations, etc. for all categories, but also
> > having inconsistent menus between computers, and worse, having apps that
> > move to a different menu when you install another app. I don't think we
> > want that.
> 
> Actually, we already have that, don't we?  If you install the Fedora
> 'geda-gaf' package, the apps appear in different places depending on
> whether you install the 'electronics-menu' package or not.  Same goes
> for Debian and the 'extra-xdg-menus' package.  I don't find this
> argument persuasive, sorry. :-)

I didn't know about electronics-menu, but this is a package that
explicitly modify the menu structure (same for extra-xdg-menus, I
guess). So if someone installs it, then he knows that he's going to
change the menu structure. That's different from, say, installing
Chromium and then suddenly getting a "Web Browser" submenu (just an
example of how this could degenerate).

[...]

> Why is the division into Main Categories and Additional Categories
> needed?

I didn't write the spec, so I can't know for sure. I can only guess that
the intended goal was to encourage a toplevel structure that would be
shared by most implementors, without enforcing this.

> Why not change the spec so that the sets are unified into a
> list of Recommended Categories. State that .desktop files SHOULD specify
> all relevant Recommended Categories, and that distributions/packagers
> MAY use additional or alternative categories.
> 
> * Existing .desktop files would not need to be modified (except to
>   remove inappropriate Main Categories that were shoehorned in due to
>   the current spec).
> 
> * Existing distributions and desktop environment implementations would
>   still be conforming.
> 
> * The list of Recommended Categories could be maintained IANA-style,
>   with new categories being added if a need is shown for them.

(we want this point for sure)

> * If an implementor only wants to use a subset of the Recommended
>   Categories, they are still free to do so.
> 
> * Distributions and packagers would have greatly improved flexibility
>   for organising menus.

This point is actually my main issue with your suggestion to relax
things more: improved flexibility will result in menus that are not
consistent from one system to another (which is already the case to some
extent today). For sure, app developers want their app to be displayed
in the menu, but in general they also want to avoid appearing in the
catch-all submenu when it exists. And this improved flexibility will
make things harder as .desktop files will not be handled the same way by
all distributors.

That's why I prefer having a recommended applications.menu in the spec.

> I would be interested in hearing your thoughts on this suggestion. :-)
> 
> Would you agree that, in the short term, the following three changes are
> reasonable, though?
> 
> 1. Delete this sentence:
> 
> > Additional Categories should always be used in combination with one of
> > the Main Categories.

I'm fine with this.

> 2. Delete this sentence:
> 
> > Note that at least one Main Category must be included in the desktop
> > entry's list of categories.

I guess I could live with that.

> 3. Add some language requesting implementors to provide a catch-all
>    submenu.

+1

Before we do the changes (I just saw you sent patches, thanks!), I'd
really like others to step up and give their opinion on the changes.

>                          Peter
> 
> 
> P.S. I just noticed that the examples of using Categories actually
>      aren't conformant with the spec at the moment. ;-)

Heh :-)

Cheers,

Vincent

-- 
Les gens heureux ne sont pas pressés.