Re: Simplified UI (menu-systems)

["Ian Bicking" <bickiia@earlham.edu>]

...
> 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 
lot better.

>   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 
> >managers.  
> 
> 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
> rpm's?).

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 
difference.]


--
Ian Bicking <bickiia@earlham.edu>