[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#361418: [Proposal] new Debian menu structure



On Sun, May 14, 2006 at 09:28:38PM +0200, Daniel Leidert wrote:
> Am Sonntag, den 14.05.2006, 21:07 +0200 schrieb Bill Allombert:
> > On Sun, May 14, 2006 at 08:58:45PM +0200, Daniel Leidert wrote:
> > > Am Samstag, den 13.05.2006, 13:26 +0200 schrieb Bill Allombert:
> > > I did not check it: IMHO it would make sense to try to be compatible (in
> > > parts) with the freedesktop.org menu specification and the structure
> > > they propose.
> > 
> > But the freedesktop.org does not propose any structure.
> 
> This is not completely true. It defines categories and sub-categories.
> There is also a structure. But I agree, that it does not explicitly

There is a concept of "related categories" but not of sub-categories.
This do not make a structure (i.e. a tree).

> define/propose a structure. But I also meant, that you should maybe
> think about to be compatible with their category naming.

But they do not propose user-visible naming for the categories,
only code names like "ConsoleOnly" or "KidsGames".

Historically, Freedesktop categories names originated from KDE menu
names that were chosen by looking heavily at Debian menu, and they still
carry problems that are found in the current Debian menu subpolicy.
I think we should move forward rather than waiting the rest of the 
free software community to do the job for us.

Due to this legacy, Debian menu section are often also Freedesktop categories
codename. However while Debian has a "Graphics" subsection and there is
a Freedesktop category "Graphics", Freedesktop does not mandate at all
that the category is presented to the user by the string "Graphics".
Indeed the exact string is defined by a .menu file which can choose
to present the category as "Image-Related softwares" or anything else.

So the consistency of naming between Debian menu section and Freedesktop
categories is purely formal and not very useful.

Debian should define a structure in accordance to the packages we
actually provide rather than in accordance to an abstract specification.

Cheers,
Bill.



Reply to: