Mailinglist Archive: opensuse-ux (48 mails)
|< Previous||Next >|
Re: [opensuse-ux] new UI in yast2-printer
- From: Johannes Meixner <jsmeix@xxxxxxx>
- Date: Thu, 8 Nov 2007 18:12:28 +0100 (CET)
- Message-id: <Pine.LNX.4.64.0711081707050.2449@xxxxxxxxxxxxxx>
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.
Since both options include "CUPS" anyway it is not really important and
hence either vanish or put at the end in brackets for those users who are
The term "server" is only confusing as well, as for most users a server and
printing have nothing to do with each other.
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
( ) 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
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
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?
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
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
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 >|