Re: Simplified UI (menu-systems)

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

...
> Well..  I AM a relational database lover, in a sence.. I often feel
> trapped when programs force me to use tree-structures.  But as for a
> menu, I like to have it as small as possible, and I will learn where
> all things are.  A menu is something I can use often, every time I
> start a program I haven't placed on the panel.
> 
> It would be possible to make another layout of the menu. Nothing
> prevents you from placing the same entry in several places or so, but
> I would personally don't like to use it.  I want it small, fast and
> unambigous.  Generally, you don't search the menu for the program you
> look for, you know where it is and just want to start it.

It seems like what we've been talking about amounts to another 
use of the menu.  Instead of just being a holder of commonly used 
programmers programs, it would also be a catalog of the programs 
installed on the computer.  I know I use my menu like this -- 
perhaps a sign that I randomly install too many packages :-P  For 
a new user to a computer a catalog can be very useful, much 
better than sorting through directories and trying to figure out what 
things are primary applications and what are helper applications or 
meant for a different context.

If there's two menus, a system-wide comprehensive menu and a 
personal menu then both roles of a menu can be served.

> >This is true.  But isn't everything potentially good for education?  I 
> 
> That is true.  But we have to start somewhere, pick one or two word
> processors we like etc.  We will have to mention to the teachers that
> will use the systems that the programs we present to them are a
> choice of a much larger pool, and why we've chosen them.

As long as it's easy for the local teacher/administrator to override 
the decisions/suggestions that come out of seul/edu then the 
decisions will be much easier to make.  You can suggest the best 
program in most subjects, leaving out more obscure subjects, as 
long as it's easy for the local person to integrate their own 
decisions into any framework.

> The howtos of today aren't enough.  There are some getting
> started-books about linux, but they are often proprietary, and often
> directed to a specific distribution.  What we have to say to the
> teachers about the main programs they will use, both normal
> applications, specific educational ones and scientific.. That is
> something we should write down and publish _free_.
> 
> 
> >useful in an educational setting.  Whatever system is created 
> >should be fairly inclusive.
> 
> Inclusive, but still specially designed for the purpose.  One of the
> good things with linux is that it doesn't require that much
> disk-space, memory etc.  We won't be able to include everything on a
> classic PC 386..

Which, I suppose, means that SQL queries to dynamically create 
a menu are a bad idea :-/  Well, I guess I never really thought it 
was a good idea anyhow.  But it should be an inclusive framework --
MS-DOS can run on anything from an XT to a Pentium XVII, after 
all, but it wasn't written with any notion of scaling.  So it's inclusive 
when it comes to computer hardware, but not software.  Linux can 
run on anything from a 386 up, with a compromise between both 
hardware and software that makes for the best use of the computer 
in most situations (how well it works on a Palm Pilot, I'm not sure).

> >Definately.  It would be nice if there was a good framework for all 
> >the small tools an administrator uses, so that it wouldn't have to all 
> >be integrated and this small tool could be created on its own.  And 
> >I suppose there is -- the command line and its associated 
> >programs.  But the command line probably wouldn't be appropriate 
> >for many of the audiences of this tool.
> 
> There are some more.. There is a graphical linuxconfiguration for
> example (I don't remember it's name, it's not in the distribution I
> use at home), where you can add users, groups, devises, etc...

Do we want to segregate system configuration from other sorts?  
I.e., would it be a good idea to let a person add users and groups, 
but not devices or other, more dangerous stuff?  It would be nice to 
let teachers manage a lot of information without having to worry if 
they would unintentially mess up the computer.  (would sudo be 
the way to deal with this?)

> Or if someone would take the great task of making a policy for rpm's
> and menu's...  That would require getting all srpm's and making good
> install-scripts to them...  Or maybe a program to convert deb's to
> rpm's, but then I don't see why you should use rpm in the first
> place?!!

Alien can do the conversion between the formats.  I don't think it's 
terribly hard to do.  But the policy bites you even after you've done 
the conversion.

However, menu information could be stripped from debs and put 
into their respective rpm packages.  Menu information could be 
added for a large portion of rpms pretty quickly that way.

> Or, maybe there is some distribution allready doing this?  There are
> lots of them, and most use rpm's.
> 
> I don't know how it is with slackware.. As I understand it, they use
> only tar.gz-packages with install-scripts?  It's really just putting
> the menu-file in the archive and write in the installscript where it
> should go..

Slackware is the one distribution I don't think we'd have to worry 
about.  Not that it's not an acceptable distribution, but when you 
choose it you choose to do a lot of stuff by hand.  

> >The KDE-like solution is definately more inclusive for various 
> >distributions.  It's also rather crufty -- not KDE's fault, but the fault 
> >of the distributions who should really be the one's doing that job.
> 
> Can we get red hat to do the job for us? :-)

Maybe... how would we go about asking?  



--
Ian Bicking <bickiia@earlham.edu>