Re: adding desktop files to misc packages
On Fri, Jul 27, 2007 at 12:29:35PM +0200, Josselin Mouette wrote:
> Le vendredi 27 juillet 2007 à 02:44 -0700, Steve Langasek a écrit :
> > So far, the only proposal I've seen for allowing users to get access to the
> > "non-default" menu entries, after they've been hidden in GNOME, is by
> > letting them hunt down a config option in a settings menu /which is nowhere
> > near the menu itself/.
> Right-clicking on the menu isn't near the menu itself? If you have
> better suggestions to make it accessible, please don't hesitate.
It wasn't clear to me that this would be togglable from right-clicking on
the menu.
Although my above criticism wouldn't apply, I'm still not altogether happy
with this prospect because you're not just hiding the applications, you're
effectively /hiding the fact that they're hidden/, by giving no UI hint that
brings this information to your attention. (If your response to this is
"but all you have to do is right click", well - I think that supports *my*
position rather well, since that's an instance where you're giving a
/verbal/ hint because there's no visual indicator in the interface itself.)
Context menus are great for operations that you know you want to perform on
the current data/window/interface element. Unhiding menu entries isn't an
operation that you know you want to perform, if you don't know that menu
entries are being hidden in the first place! So it's imperative that hiding
menu entries in this way is only used for *very* esoteric tools that are
just plain incompatible with the environment; not just for applications that
don't meet some aesthetic standard, or that you (or someone else) think are
unlikely to be used.
(I guess it's reasonable to consider console applications "incompatible with
the environment", but then, hasn't GNOME itself supported, since long before
.desktop files existed, marking apps as "runs in xterm" in launchers?)
> You make it sound like somehow I would dictate what would be in the menu
> by removing any application I don't like or use. This has never been my
> intent. I have quoted window managers and console applications as
> examples because they are the only identified classes so far; it is hard
> to tell what will need to be excluded until the desktop files are
> actually created and we can start seeing what the menu looks like.
Why is this hard to tell? Are the kinds of things that would need to be
suppressed not evident from the menu policy?
> In the end, the people who know whether an application should be given
> tags that will exclude it from certain menus are the application's
> maintainers, not the menu systems maintainers. So far they have been
> reasonable about what is included in the menu, and I have no reason to
> think this wouldn't remain like that.
In that case, I guess I'm confused, because I had the impression that you
were still opposed to migrating the existing Debian menu to use the
freedesktop standard.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
vorlon@debian.org http://www.debian.org/
Reply to: