Hello, On Nov 8 14:19 Martin Schmidkunz wrote (shortened):
Based on your ideas I generated another mockup, which is visible and open for discussion on http://en.opensuse.org/YaST/Printer as well.
The main changes are: * Remote access settings were moved to the basic settings
* Network interfaces summary was skipped because this information should either be shown in the network interface module or in the firewall module (as internal zone)
I wonder what the purpose is. I guess it is only to remind the user about the basics of his network settings?
As I am no expert in printing I would like to ask: Global Settings
* Is it really necessary to test the remote IPP access? * Isn't the default queue selected as well when the user chooses to use the settings of the remote CUPS server?
CUPS server settings
* Which kind of "default" would be restored? * Is it really necessary to edit the CUPS config file via GUI?
I have the general problem that I do not understand the meaning of "remote CUPS server" in this dialogs. I guess what there is behind the "remote CUPS server" is a so called "client-only setup", see http://en.opensuse.org/SDB:CUPS_in_a_Nutshell If "remote CUPS server" means "client-only setup", then the organization under the "CUPS server settings" tab is wrong because "basic settings" and "listen to IPP broadcasts" belong to the local CUPS server which should be totally and strictly separated from any "remote CUPS server" stuff. If one has at least one local queue, one must run a local CUPS server (i.e. a local cupsd), otherwise the local queue doesn't work. I.e. if one has at least one local queue, and if "remote CUPS server" means "client-only setup", then "remote CUPS server" should be deactivated. If one has no local queue, but there is one single remote CUPS server which broadcasts his remote queues for printing, the user can choose either if he likes to run a local CUPS server and use the broadcasted remote queues via the so called "Browsing", see http://en.opensuse.org/SDB:CUPS_in_a_Nutshell or if he likes to do a "client-only setup" so that no longer a local CUPS server runs but the one single remote CUPS server is used directly. If there are more than one single remote CUPS server which broadcast their remote queues for printing, the "client-only setup" doesn't work well because only one single remote CUPS server can be configured for a "client-only setup". Here it is recommended to run a local CUPS server and use "Browsing". If there is no local queue and there is one single remote CUPS server with remote queues which are accessible from the local host but the remote CUPS server doesn't broadcast his remote queues, then a "client-only setup" is recommended because otherwise the remote queues are not "seen" on the local host. If there are one or more remote CUPS servers (more precisely whatever hosts which listen at port 631 - e.g. network printers) but their queues are not accessible from the local host, then any kind of "use remote CUPS server" is nonsense. There are more and more nice looking design ideas but there is almost no progress how to make the underlying structures, dependencies, and relationships clear to the user. I think dialogs with all theoretically possible choices available don't help. We must much more guide the user in a step-by-step process to what he finally wants to get. Basically tabs offer all possible choices. All what could be done is gray-out something which looks ugly because any user would like to know why something is grayed-out. Even worse is to hide something because then we may get maximum confusion when something is there for one user but not for another user and again any user would like to know why this "something" is not in his dialog. Wizard-style can much better guide the user. 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