Hello, On Nov 8 16:21 Sven Burmeister wrote (shortened):
Which user that is new to Linux knows what CUPS is or why "server" has anything to do with printing.
Yes!
Since both options include "CUPS" anyway it is not really important and should hence either vanish or put at the end in brackets for those users who are interested.
Exactly!
The term "server" is only confusing as well, as for most users a server and printing have nothing to do with each other.
Right! What we must somehow make clear to the user is that under certain circumstances (see my other mail) there is no need to run the cupsd on his local system but he should use a "client-only setup". The reason is that a "client-only setup" provides direct communication with the remote CUPS server which usually works better than when there is a local running cupsd in between (e.g. much easier to query and cancel print jobs on the server). Since CUPS 1.2 (i.e. since openSUSE 1.2) there is by default not much more security when there is no local running cupsd because since CUPS 1.2 the cupsd listens only on localhost via TCP (via UDP it still listens also on external interfces because otherwise "Browsing" cannot work).
So I would suggest to simply put:
Print via: ( ) Printer attached to this computer ( ) Printer attached to a remote computer
( ) Printer attached directly to the network But now I don't understand what I should choose when there is a network printer but I know that there is a print server in my network which is resposible for all network printers. Note that usually one cannot send data to a network printer in a company because the company admin has set up the network printer to accept only data from the company print server. Perhaps "Printer accessible via a remote computer" would be the right wording but now it may look strange for an unexperienced user. It seems we still need to find out which questions we must ask the user so that he understands what we like to know and so that we understand what there really is in his network.
Further the term "queue" might also be replaced by printer, even if that simplifies it a bit but for most people the printer is what queue means. For those that have more than one queue and only one printer it will still make sense since a queue is just the same printer with different settings.
I agree and I disagree. On the one hand all other printer setup tools mix up "queue" with "printer" so that users are used to have this confusion in their minds and for compatibliliy reasons we could simply also use "printer" when we mean "queue". This results nice wording like: "Set up one more printer for the same printer?" ;-) But so many problems exist because users think the "printer" inside their computer is equivalent to the piece of hardware outside of their computer. This leads to wrong assumtions in the user's mind how the printing system works and the consequence are problems. E.g. when users query the queue and get a good result but the actual printer prints crap or when the queue is "ready" but the actual printer is e.g. "offline". In the past we tried to make the user aware that it is actually a "queue" what is set up in their system but the longer I watch to where we move, the more I don't care if it is really correct what we show to them as long as our users like it. Actually queues and printers are very different things. A printer is a piece of hardware. A queue is basically a named output channel which (hopefully) results correct output on a printer. One can have printers but no queues. One can have queues but no printers. One can have anything else in between. The basic reason of all this confusion is: ------------------------------------------------- | There is no printer in the printing system. | ------------------------------------------------- What I mean is that there is no software representation of the real piece of hardware in the printing system. The kernel or whatever low-level system has a software representation of a printer, for example the USB device IDs which "lsusb" shows or what a kernel module gets during autoprobing of the parallel port or what an SNMP tool may detect in the network and so on, basically what the CUPS backends show when they run in device discovery mode. But once a queue was set up, the printing system does not remember the software representation of the real piece of hardware for which the queue was set up. All what is done is that from the software representation of the real piece of hardware a more or less abstract description is derived (the so called DeviceURI) which describes only how the the piece of hardware is connected to the computer so that the printing system (the CUPS backend) can send its data out of the computer. But nothing in the printing system knows what there is really at the end of the "named output channel" - i.e. the "queue". Some examples of bad consequences: What happens if a printer is disconnected from the parallel port and replaced by a different model? Nothing happens. The printing system would not notice that a different piece of hardware is now at the end of the connection. The printing systen still sends the same kind of data out of the computer and in the best case the new piece of hardware doesn't print anything but in the worst case it prints tons of sheets with meaningless nonsense characters. The same bad consequence if a network printer is replaced by a different model (with same IP). What could be done if a user likes to find out for which printers in his environment (in particular think about a bigger networked environment in a company) there exists already a queue and for which printers not? Nothing can be done by software. It is up to the imagination of the user to check the info strings of the queues which he might see by luck on his local system to find out which queue matches to which printer. Furthermore a reliable printer autoconfig tool cannot exist because in general it is not possible to find out for an autodetected printer if there exists already a queue for it. One can do some "best guess" based on the usb DeviceURI but there is not only the usb backend for USB printers. Perhaps this is also the reason for https://bugzilla.novell.com/show_bug.cgi?id=334166
The "Save debugging information..." should state where it is saved, because new to Linux users don't know where the logs are or how to access them. One could for example give a hint to YaST > Other > Logs.
Or even better provide also a "View debugging information" (of course with a [Search] option ;-) I think it doesn't make much sense to offer only half of whatever nice-to-have functionality - then better no such nice-to-have functionality at all (e.g. when there is not enough manpower to implement and maintain the complete nice-to-have functionality). 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