[RFC] Fixing the Desktop Menu Specification.

[Vincent Untz]

(hrm, I had written a reply to this mail, but I apparently didn't send
it?!)

Le lundi 14 novembre 2011, à 14:03 +0000, Peter Brett a écrit :
> 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.

My point is that a package that automatically installs something
changing the menu structure that affects other applications is, imho,
broken.

But let's not fight over 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.
> 
> I like the idea that specialist distributions can have specialist menus
> and still be conforming.  Saves arguments. ;-)

Nod. I'm sure I had something to reply to this, but since I forgot, I
guess it didn't matter ;-)

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

That could work, yes.

I'd really like other people to voice their +1 and/or -1... If nobody
else replies to this thread within the next week, I'll just consider we
can go crazy and do what we want with the spec.

Thanks for pushing this, btw!

Vincent

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