Re: [PROPOSED] moving the menu hierarchy into debian policy
Joey Hess <joey@kitenet.net> writes:
> Because they were designed for menus. It's really a very different thing.
> With menus, you have some constraints:
Some of which we can achieve, some maybe not.
> * You need to put commonly accessed menus as close to the root as possible.
> That's why the XShells menu is right on the root, because we know people
> start more xterms than anything else.
This is why *my* number one, absolute top priority for changes to the
current menu system is to put in a TOP LEVEL ENTRY NAMED "Help". With
at least: "Debian Online Help" (currently hidden in Apps/Tools), Gnome
Help (currently in Apps/Viewers), tkinfo (currently in Apps/Viewers),
and xman (location unknown). This is SOO important for novices!
> * You need to limit menus to no more than 15 items, 10 is better. Otherwise
> they won't fit on some screens.
This is a whole 'nuther ball of wax. Joost mentioned this when I
discussed menus with him. The problem is that you cannot predict
which packages will be installed, so you need to write some sort of
intelligent heuristics. If you just create a wider, deeper set of
categories, you're going to end up with all sorts of nearly-empty
menus on a lot of peoples systems (most?). Which is Not Good. There
is a *lot* of work involved in trying to achieve this one. Therefore,
I suggest we ignore this issue until we come up with a Good scheme.
> * One package can install menus items in any number of different menus. Look
> at bsdgames.
No problemo.
BTW, note that I cc'd joost on this. He asked to be cc'd into any
policy discussions about this topic. So, while it's probably a waste
of time, I'd like to request that everyone else cc him, but *not*,
please, every other participant.
--
Chris Waters xtifr@dsp.net | I have a truly elegant proof of the
or xtifr@debian.org | above, but it is too long to fit into
http://www.dsp.net/xtifr | this .signature file.
Reply to: