Re: Simplified UI (menu-systems)

[Fredrik Liljegren <eof@hem.utfors.se>]

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

A menu-system that isn't hierarchical?  As long as you dont put
averything in the main menu, I don't really know what you mean..


>sources.  Like adding icons to applications that don't have them, 
>you can never keep up.

We can have icons for all programs we think are good educational
stuff..


>> "/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.
...
>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.

It would be quite easy writing a simple tool for making these groups
and managing them.  I think, though, it could be better if it would
be fitted in to a more general administrators tool.  I saw that the
sowftware-page had a pointer to a good program for administrating
large group.  I haven't tried it, but maybe it could be fitted in
there?


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

No, that's the big thing.  In a debian-system, the global menu
contains allmost every application installed.  In a red
hat-enviroment, only the one we chose to will be in the menu.  Maybe
that isn't such a bad thing, if you want a menu specifically for
aducational use...


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

Ok.  But maybe there is a better way of doing it.  I know that for
kde, when you don't use debian, there is a program that seeks up
applications on the system.  I don't know how it chooses, but somehow
it finds most of them and put them in the menu.  If we were to have a
general package with howtos, descriptions of the different programs
and examples of usage, maybe that could contain a program that could
be run by the init-scripts to update when necessary?
  I know that for example ldconfig is run in startup on several
systems, to check for new libraries.  In debian, it's by policy used
whenever a package installed or removed a library.

For me, and the schools I hope to install and maintian a GNU/Linux
on, this question isn't hard, I use debian.  But as I've read earlier
on the list, there won't be a single distribution for this, because
we could never solve that "distribution-war" that's politely silent
among the whole community of linux...  As for seul's independance..
Trying to make it easier to install a pre-configures linux-system is
a good thing, but the things we make have to be usable on all
distributions.


.../EOF
---
<mailto:eof@hem.utfors.se>
Educational Free Software - http://hem.fyristorg.com/edufs/