[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freedesktop-xdg
Subject:    RE: PATCH: Menu Spec - Categories
From:       Frederic Crozat <fcrozat () mandriva ! com>
Date:       2006-09-25 11:31:53
Message-ID: 1159183913.12579.70.camel () trinidad ! mandrakesoft ! com
[Download RAW message or body]

Le vendredi 08 septembre 2006 à 13:17 -0700, Bastian, Waldo a écrit :
> > Le jeudi 07 septembre 2006 à 18:30 -0700, Bastian, Waldo a écrit :
> > > The menu spec currently makes some weak recommendations with regard to
> > > how categories are to be used. The reality however is that for an
> > > application to show up in the application menu it must either define its
> > > own submenu or use a category out of a small defined set. The menu spec
> > > doesn't make clear what that set is although it does provide some hints
> > > in the right direction. What is also missing is a requirement that
> > > desktop environments must continue to support this core set of
> > > categories. Failure to do so would result in applications no longer
> > > showing up in the menu which clearly can't be the intention.
> > > 
> > > The above situation is compounded by the fact that Gnome based
> > > implementations only place "Unallocated" entries in its menu if these
> > > entries list the "Application" category. The menu spec does not mention
> > > "Application" as category. We can either ignore this and effectively
> > > killing the "OnlyUnallocated" fallback, or add to the spec that all
> > > desktop files should include "Application" as category.
> > 
> > I'm sorry I can't participate more in this discussion (I'm too busy
> > finishing our Mandriva 2007.0 release, I should have more time in about
> > two weeks) but you might want to have a look at one document I wrote for
> > our transition to full "XDG" menu for Mandriva Linux 2007.0 where we
> > discovered "missing" categories, compared with our earlier menu
> > structure :
> > http://qa.mandriva.com/twiki/bin/view/Main/MenuMigrationToXDG
> 
> It shouldn't be a problem to add some additional secondary categories to the spec.

I'd like to propose the following additional categories to the spec :
Compression => Archiving isn't verbose enough for utilities like ark or
file-roller
Fax => Fax management software don't fall into Telephony current
description (Telephony via PC)
Chat => IRCClient is a little too much specific, an alias called Chat
should be added, or IRCClient description should be much broad.
VideoConference : currently, Telephony is only for VoIP, so videoconf
applications don't belong in Telephony (or we could improve Telephony
description to include VideoConference apps)
Printing (or Printer) => HardwareSettings might be a little too crowed
and there are a lot of printer tools which can justify adding this
category
Documentation (or Help) : self explanatory :)
FileTools : FileManager is too specific for various random file tools
(like getting file space usage, etc..)
TextTools: tools to manipulate text file, such as dictionary, etc..

a bunch of Sciences subcategories :
ArtificialIntelligence, ComputerScience, DataVisualization, Electricity,
GeoSciences (well, this one might be covered by Geology..),
ImageProcessing, NumericalAnalysis (could be covered by Math),
ParallelComputing, Robotics

a bunch of Education subcategories :
Economy, Geography, History, Literature, Sport

We are also missing a category for telephony stuff but not related to
VoIP, but instead for applications managing phone systems, dialing a
number, using a terminal emulator, etc.. I haven't figured a nice
caterogy name for that, sorry ;)

> 
> > Another thing which is missing in the current spec is some kind of
> > two-pass for category matching : there is no way to specify some
> > categories have more priority than other. For instance, as a vendor, we
> > might want to move some entries to another category (so we add our own
> > vendor category) but keep fdo category matching (maybe in another
> > location in the menu tree). With current category matching, menu entry
> > will be duplicated.
> 
> There is two-pass (and exactly two) category matching. You can use the  \
> <OnlyUnallocated> tag to do the matching in the second pass. Note that that tag \
> must be a child of the <Menu> tag, it's not a matching predicate.

Unfortunately, OnlyUnallocated isn't flexible enough to be really useful
for something else than "trash bin where we store anything we couldn't
match". 

> > Another missing thing is a way to add a preference for category or
> > layout matching based on ShowOnlyIn, allowing us to ship one menu
> > description file with different menu order and matching for GNOME and
> > KDE (favoring GNOME applications when running GNOME, KDE apps when using
> > KDE).
> 
> I'm working on a patch to allow desktop specific applications.menu files as \
> currently used by Kubuntu and others.

I'm not sure it will solve exactly what I was writing about and
moreover, it will add file duplication. But we will see.

-- 
Frederic Crozat <fcrozat@mandriva.com>
Mandriva


[prev in list] [next in list] [prev in thread] [next in thread]