[RFC] Fixing the Desktop Menu Specification.
peter at peter-b.co.uk
Thu Nov 10 08:58:12 PST 2011
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...
> 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.
>> I think the problem is that, at the moment, the Main Categories are
>> assumed by the specification to form a complete ontology, but they
>> 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. :-)
> Thinking more about that, I'm not convinced the issue is about
> categories themselves . I believe the main issue is that desktops and
> distributors are shipping different applications.menu, which makes it
> really hard for app developers to do a right choice for the categories.
> Fixing this would, hopefully, also help fix your issue.
Although I agree with you that fixing this would *help*, it still does
not address the issue that, for some applications, it is not currently
possible to write a correct .desktop file.
>  of course, we do have issues with the categories, and we should
> still fix them: some are missing, some are useless now, their
> descriptions are broken, it's often unclear which one to choose for an
> app developer, etc.
Why is the division into Main Categories and Additional Categories
needed? 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.
* 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.
I would be interested in hearing your thoughts on this suggestion. :-)
Would you agree that, in the short term, the following three changes are
1. Delete this sentence:
> Additional Categories should always be used in combination with one of
> the Main Categories.
2. Delete this sentence:
> Note that at least one Main Category must be included in the desktop
> entry's list of categories.
3. Add some language requesting implementors to provide a catch-all
P.S. I just noticed that the examples of using Categories actually
aren't conformant with the spec at the moment. ;-)
Peter Brett <peter at peter-b.co.uk>
Remote Sensing Research Group
Surrey Space Centre
More information about the xdg