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

List:       debian-devel
Subject:    Re: adding desktop files to misc packages
From:       Frank =?iso-8859-1?Q?K=FCster?= <frank () kuesterei ! ch>
Date:       2007-07-28 15:12:54
Message-ID: 87odhw7ea1.fsf () riesling ! zuerich ! kuesterei ! ch
[Download RAW message or body]

Josselin Mouette <joss@debian.org> wrote:

> Le jeudi 26 juillet 2007 08:25 +0200, Frank Küster a écrit :
>
>> Could you give guidelines how a maintainer of an application should
>> classify their app,
>
> Using categories described in [0] is a good start. The maintainers would
> also have to agree on new categories if the ones listed are not
> sufficient.

To me, these categories look very poor, I really wouldn't want the
well-structured debian menu (note that I'm talking about the new Debian
menu, not the default menu for etch) to be replaced by anything like
this.  To me, it rather looks like it doesn't make sense to add
additional ones, given that we already have something much better.

Moreover, this doesn't answer my question at all, but I was probably
unclear.  What I meant was "How (do you think) should a maintainer
decide whether a particular application is marked as "not for Gnome", or
"not for desktop environments", or such.  I wanted something more
general than "Python should be hidden", "switching windowmanagers should
be hidden", because it's hard to discuss whether this hiding thing makes
sense when I have no idea what you think should be hidden, except some
special examples.

> On the
> contrary, NotShowIn should be used if similar functionality is available
> in one or several environments and displaying an icon would only be a
> source of confusion.

Okay, that makes sense - a frontend to setxkbmap shouldn't have a menu
entry when there's a specific tool for customizing the keyboard for the
desktop environement.

That's the type of general guideline I'd like to see, but this
particular one won't catch many applications.

> For applications that aren't useful in the general case, NoDisplay=true
> should be set. Let me show an example: gstreamer-properties used to have
> an icon in the menu. In current releases, the appropriate sinks to use
> (esd, alsa, etc.) are autodetected which means there is no *need* for
> users to launch it, and this allowed us to set NoDisplay=true. The same
> should hold for configuration dialogs that are specific to an
> application and already available from it.

That also makes sense, but here I would argue that those shouldn't have
a menu entry at all.

>> and how Gnome would decide which classes to hide?
>
> ConsoleOnly, Shell, Screensaver, X-WindowManager are good candidates. We
> could also exclude things like FileManager as nautilus is always
> launched, for example. 

ACK

> Sound judgement should do the rest.

I'm sceptical about that.  Up to this discussion I didn't even have an
idea that people might want to hide things from the menu, and I still
don't feel I understand exactly what and why you want to hide.  But it's
going to be the package maintainers like me who assign these classes, so
we'd better give them some guidelines.


One guideline could be "if there's an application for doing $foo that's
provided by the desktop environment, only show this one".  Maybe that is
what you applied when you suggested to not display other file managers
besides Nautilus.

However, I don't think this is a good rule in general: If both
$gnome_wordprocessor and openoffice.org-writer are installed, I'm sure
it would confuse users if there was no menu entry for
openoffice.org-writer.  Or, nearer to my own packaging work, if someone
starts to learn LaTeX, and all they find in the menu to look at DVI
files is evince or kdvi or similar, while everyone in the LaTeX
community only talks about xdvi (and for a reason).

Regards, Frank

--
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)


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