Mailinglist Archive: opensuse-ux (48 mails)

< Previous Next >
Re: [opensuse-ux] Next Shot for a Redesign of YaST Control Center
  • From: Johannes Meixner <jsmeix@xxxxxxx>
  • Date: Thu, 29 Nov 2007 14:05:42 +0100 (CET)
  • Message-id: <Pine.LNX.4.64.0711291327310.19992@xxxxxxxxxxxxxx>

Hello,

On Nov 29 12:56 Martin Schmidkunz wrote (shortened):
I have seen much too much nice looking design ideas for setup tools
which simply cannot be implemented correctly because they are against
the design of the underlying stuff in the system.

I wonder what the underlying stuff might be in our case?

I meant it as a general comment.

In the particular case of the YaST Control Center,
the underlying stuff is that YaST is open source
so that whoever likes can make as many additional modules
as he likes so that the YaST Control Center must be able
do deal with zillions of modules.

Think about third-party software vendors or hardware manufacturers
which make YaST modules to set up their software or hardware.

Or in other words:
Accept that there are zillions of modules.
Then find a YaST Control Center design how to deal with it.
Not vice versa.


Nonetheless, we should carefully check, whether some modules make sense
the way they are.

Of course - but this is a different issue than the
YaST Control Center redesign.

I think we must carefully keep different things separated
in the discussion ;-)


If I got it correctly, the assumption is, that zillions of modules are
similar to zillions of options.
I am not sure about that.
IMHO you do not have zillions of options in a control centre, but just
one and that is to pick the right module.

It seems we are back at the problem to distinguish between items
from which the user can freely choose one (e.g. printer resolution)
and items where the user must select the right one (e.g. paper size).

Usually YaST modules are the latter case.

But remember that e.g. third-party software vendors or hardware
manufacturers can make YaST modules to set up their software
or hardware so that there might be more than one module
to set up a printer, graphics card, scanner, monitor, ...
or to set up a firewall (e.g. a third-party firewall).
A redesigned YaST Control Center should not fail in this case.


Perhaps the ideas regarding "dealing with 5,000,000 use-cases" at
http://www.mmiworks.net/eng/publications/labels/openPrinting.html

That is an interesting approach.
If I got it right, it emphases the tasks, the user wants to accomplish
(e.g. paper saving, impressive printing), which can be combined by using
a matrix.

Yes!

For the YaST Control Center one could have tasks like
"set up Internet and networking stuff"
"set up printing and scanning"
"set up graphics stuff (mouse, monitor, graphics card,...)"
"set up security stuff"
"set up console (keyboard, mouse/GPM, framebuffer, ...)"

For example the YaST Firewall module could be accessible
both via "set up Internet and networking stuff" and via
"set up security stuff" and the YaST Mouse module
could be accessible both via "set up graphics stuff"
and via "set up console".

This would also avoid the usual bloatware bugs with too huge
unmaintainable all-in-one modules (e.g. several separated
modules for separated tasks regarding networking and security
become mixed up in a network-bloatware module).

In particluar think about the runtime-monster when e.g. the
small YaST Scanner module calls the small YaST Firewall module
(for a few Firewall settings regarding scanning in the network)
but instead a huge YaST network-bloatware module is loaded
into memory and it starts to do all its bloatware work
(e.g. autodetect network cards, modems, ISDN adapters, ...)
if the system didn't collapse with "out of memory" before ;-)

Have high-end enterprise systems in mind where on one
physical hardware many Linux instances run (IBM Z-Series,
XEN, VMware,...) so that there are not too much resources
for one particular Linux instance.


Kind Regards
Johannes Meixner
--
SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany
AG Nuernberg, HRB 16746, GF: Markus Rex
--
To unsubscribe, e-mail: opensuse-ux+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-ux+help@xxxxxxxxxxxx

< Previous Next >