[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Simplified UI (menu-systems)
>> 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
>> "/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'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
>[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
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
Educational Free Software - http://hem.fyristorg.com/edufs/