[RFC] Fixing the Desktop Menu Specification.

[Peter Brett]

Vincent Untz <vuntz at gnome.org> writes:
> [snip]
>
> Le jeudi 10 novembre 2011, à 16:58 +0000, Peter Brett a écrit :
>> > 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).

Surely you're assuming that the user is also the person installing
packages?  I think that's an invalid assumption.

> [...]
>
>> 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.

I would agree with you, if it wasn't for the "treat this as a complete
ontology even though it isn't" wording.

>> 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.

I like the idea that specialist distributions can have specialist menus
and still be conforming.  Saves arguments. ;-)

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

How about both: remove the distinction between category classes, *and*
include a recommended applications.menu?

                      Peter

-- 
Peter Brett <peter at peter-b.co.uk>
Remote Sensing Research Group
Surrey Space Centre