[RFC] Fixing the Desktop Menu Specification.

[Vincent Untz]

Le mercredi 09 novembre 2011, à 16:54 +0000, Peter Brett a écrit :
> Vincent Untz <vuntz at gnome.org> writes:
> > Le mercredi 09 novembre 2011, à 15:57 +0000, Peter TB Brett a écrit :
> >> All conforming implementations of the desktop specification (that I am
> >> aware of) display *only* the Main Categories unless explicitly
> >> configured otherwise.  Any application that fails to include one of
> >> the Main Categories in its .desktop file is (at best) shown in a "Lost
> >> and Found" virtual category, or not displayed at all.
> >
> > This could be fixed by changing the applications.menu shipped by the
> > various people; I'm not entirely sure adding a new main category will
> > help since it won't automatically lead to it being used in
> > applications.menu, but we could try.
> >
> > Alternatively, or in addition to that, we could suggest a default
> > applications.menu in the spec.
> 
> I think the very minimum changes that the specification needs are:
> 
> * Stop requiring every .desktop file to include a Main Category.
> 
> * 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.

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.

> >> Or will someone finally propose a way out of this situation?
> >
> > Maybe we can start with a proposal and discuss it? Even if it was
> > discussed in the past, time has passed and people might have a different
> > opinion now.
> 
> 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.

Thinking more about that, I'm not convinced the issue is about
categories themselves [1]. 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.

Vincent

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

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