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@opensuse.org For additional commands, e-mail: opensuse-ux+help@opensuse.org