[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Simplified UI (menu-systems)
> With KDE (and GNOME I think), you can easily make a personal menu
> with the programs you use, or have them on the panel, by in a
> graphical program choosing from the systems menu. A teacher talking
> about Dr Geo for instance, can at one time mention that it's under
> "Education/Math" or something. The student can then easily choose to
> place it on their own menu.
> That way, all the programs are in one menu, the kids' favourite in
> another, and exploration of all programs can easily be done.
I think this is sounding like the best solution, if it could be matched
with a better menuing system -- one that isn't quite so hiarchical.
But I don't know how one would go about this... it's not hard
intellectually, it just involves categorizing things from diverse
sources. Like adding icons to applications that don't have them,
you can never keep up.
Maybe a hiarchical menu with local modifications is enough...
> >or less). I don't know the exact mechanics behind this, but I
> >imagine that it would be possible to do more than just X -- like a
> >high school category, an elementary category, etc.
> I don't know if the menu-system can recognize any user-category or
> so, I think it's just requirements for making it work.
I'd imagine you could manipulate requirements to do the same
function as categories. That's probably a rather crufty solution,
though. I think the solution of moving things around is probably a
> What could be done, is that the group of pupils' "~/.menu/" is
> linked to a single (write-protected) directory somewhere. Adding a
> program in there would then add it for the whole group. Or, you can
> make it a double pointer. You can have
> "/etc/menu-groups/high_school/", "/etc/menu-groups/primary/" etc.
> The users .menu would point to a virtual /etc/menu-gourps/class_3A,
> wich in turn could be moved as they move along. A simple re-link
> would change the whole category.
That sounds like a of nice solution. It does require the
administrator/teacher to manage things quite a bit. I guess that's
positive and negative at the same time -- it can be convenient to
get everyone on the same page, so to speak, while it also requires
that the administrator be very attentive to the students' menus --
something that probably would be best if it didn't take much effort.
But with a few automated utilities it could provide some easy
reorganizing of the menu. For instance, a simple utility could
create a new category and make a copy of a menu entry from, say,
"Apps/Editors" to "Class/Web Publishing". If the system also
supported both global (complete) menus and personal menus then
the symbolic links probably wouldn't be necessary -- the local
changes would be enough.
> >However, Debian menus aren't easily manipulated. But it would
> >probably be much easier to make the few small utilities necessary
> >than to recreate a menu system that interacts with many window
> The problem with this is that is't debian-specific.. Well, off
> course the programs could be used with rpm's as well, but the process
> isn't automated in the same sence, the administrator would have to
> run eg update-menus by hand (I think, there aren't install-scripts in
There's nothing terribly Debian specific about the Debian menus
except for a menu policy in the packaging guidelines -- that
programs that deserve a menu entry list themselves, and that
programs that use menus say how it is they accept menus. Any
specific problems porting to a different distribution can be solved
without too much work, but adding that information to *every*
package is not easy.
Anyway, the Debian menus provide free code that implements
most of the hard parts.
[rpms do allow scripts, they just aren't typically used well. The
technical differences between rpm and deb aren't very great from
what I can tell -- it's the policies behind them that really make the
Ian Bicking <email@example.com>