Stefan Hundhammer wrote:
After reading so many dozens of utterly off-topic posts in the first thread I
gave up.
The first thread was not meant to be about generic wishes about YaST and
related. It was not about a complete rewrite of everything. It was not about
what could be improved in various individual YaST modules. It was not about
bugs that could be reported with Bugzilla. It was not about dropping the
ncurses text mode (we don't plan to do anything like that).
Rather, it was about
The YaST Control Center
in particular the Qt version.
This is the small, very basic, Qt-only (very little dependencies, in
particular not to the entire YaST engine) application that starts YaST
modules. Some people call it the YaST shell. Currently, it looks like this:
http://en.opensuse.org/Image:YaST_Control_Center.png
And THIS is what we want to change. THIS is what we want a radical new
approach (or, at minimum, a radical new look).
So please, let's start over and PLEASE let's focus on the topic. We think
community input is important. We think some of you out there might have a
really great idea how we could do this control center thingy better.
We identified a number of problems with that old control center:
(1) There are too many icons in there - way more that can easily be navigated.
(2) The groups don't always match users' expectations.
(E.g., is firewall more related to security or to network?)
Put the firewall icon and it's hook in BOTH places.
Problem solved.
(3) It's hard for newbies to figure out what does what.
Unfortunately, there is no magical cure for a lack of knowledge
other than the person going out and obtaining that knowledge.
Every time I replace my car, I have to learn a whole new
system of steering-column controls -- and very much so
if the car is from a different automaker than the one
before it.
(3a) Sometimes it's hard to figure out the difference between modules.
(4) It's often enough hard for expert to find things.
(5) It's not exactly pretty.
When I'm trying to get something done, that's the
least of my concerns -- just as long as it's not in
a color combination which is hard to read (like, say
red text on a blue or green background) or otherwise
an annoyance to the point of anger.
Back when we designed that control center, we figured it would do its job
fairly well. But that was when we only had a small number of modules. And eye
candy was less readily available from the underlying toolkits. Time has
changed since then. I counted no less than 119 YaST-related .desktop files on
my machine (not counting the groups files). That corresponds to 119 icons
that have to be presented somehow. That just doesn't scale any more with the
old control center approach.
So in the ideal case we would like to have a completely new approach.
This is what that "radical change" was all about.
Maybe there is a different way than just placing a lot of icons in a window
(with or without groups) and let the user figure out how to deal with it.
Carefully taking care, of course, of all kinds of users, newbies as well as
experts.
There could be some things done differently, say
General Networking, and then, things like NIS could be
put in something like "Large/Commercial Site Networking"
which would indicate to the newbie at home that
NOTHING in there is applicable to his home set
up -- even if he has 5 computers on his home network.
[An additional comment in the sidebar could be:
"If you do not understand the things in here,
SuSE recommends that you leave them alone.
These are tools for experienced, professional
administrators in large-scale commercial,
academic, etc. environments"
Failing that, maybe somebody has a good idea how to present the modules
traditionally in an icon view, but in a way that does not overwhelm everybody
when the window opens (the "show all at once" approach) or that leaves the
user searching for the right module at most times (the icon groups or even
icon tree approach).
This is what that was all about. This is what we ask your opinions for.
Basically, what you're saying is, the tree needs to
be modified. I have no argument with that. Perhaps
the solution is more main branches, and/or to add
sub-branches within the main branch.
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
