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

Bug#243375: kdelibs-bin: menu-method freedesktop should set the Generic Name Field to longtitle instead of title



On Sat, Jul 03, 2004 at 02:08:24PM +0200, Dominique Devriese wrote:
> > The documentation is clear about that:
> 
> > <p> The fields <tt/needs/, <tt/section/, <tt/title/ and <tt/command/
> > are mandatory. Other fields are optional. Custom fields are
> > supported, so you can add new fields for you own purpose.
> 
> Right, I must have missed that.  How about adding longtitle and
> genericname to the mandated list ?

Because they are not mandatory for proper menu operation.

> > I don't think it will happen, or even that it is a good idea. Most
> > upstream .desktop (outside KDE or GNOME core) are made to advertise
> > the software rather than trying to build a consistent menu
> > structure.
> 
> Do you have examples of that ?  Wouldn't it be the job of the people

Consider asciijump as an example. 

> packaging the apps to fixup their .desktop files ?

Then there are no real benefit to use .desktop over menu files if you
have to edit them anyway. Experimentaly, people are more careful
when writing a new file that when editing upstream files.

> > I wonder if it would not be more worthwhile to keep the Debian menu
> > as an 'omnibus' menu, and reserve the xdg menu for the desktop
> > environnement. This way, the menu would provide a more consistent
> > desktop experience.
> 
> I don't really agree with the difference between what you call "the
> desktop environment", and other applications with menu methods.  In
> what way do these categories have different needs ?

I have no opinion myself, since I don't use desktop environments.
However reading comments about menus, I have seen several kind of users:

1) Users that want a menu with all available programs.

2) Users that want a menu with only 'Desktop' apps, say KDE programs and
openoffice.org. They claim that a menu entry for emacs e.g. is useless and 
confusing for newbie.

3) Users that prefer the Debian menu layout.

Having a separated (omnibus) Debian menu would let users 1 and 3 use it,
and do not get in the way of users 2). Of course, this is a compromise 
solution.

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 



Reply to: