JP Rosevear wrote:
1) Detecting a local USB printer when plugged into the machine and
prompting the user to configure it or automatically selecting a driver
and configuring the printer
We have a lot of the detection code, both usb and hal cups backends can
detect the usb printer.
Please keep in mind: this discussion should not be restricted to usb
and hal backend, also the vendor specific backends should be
supported: hp:, hpfax: (both from the full OpenSource project hplip),
epson:, and many more to get the best printing results from a printer.
Hal being a general hardware detection layer
actually sends a message when its plugged in and GNOME uses this to pop
up a dialog to configure the printer via a hal backend for cups.
However the hal backend is not a standard upstream cups backend and its
very difficult to convert a cups hal:// uri to a usb:// one - but not
entirely impossible, there is some code in /usr/bin/add-unknown-printer
(part of the gnome-volume-manager) to do some of this.
We need to mention that the current hal backend needs to be extended
to satisfy the new requirements, which actual CUPS system expects
from backends. But it seems that upstream developers didn't work on
this opportunity till today.
Yast also does not support the hal backend currently.
The usb cups
backend is the standard upstream cups backend but it does no polling
so we'd need to poll somehow (gnome-volume-manager and kmediamanager
Hmm. I had a quick look at the current hal/dbus architecture. I didn't
see any pollin by any device so far. Instead an administration process
called by the hal/dbus system is executed. I'm speeking about the
Maybe I'm wrong...
But if not, then we might replace the hal backend by _any_ backend,
and no need to use no longer developed tools (hal backend) is needed.
Instead we can use our own mechanism here, even YaST, as soon as YaST
supports installation of printers without any need of user feedback
I want to point out, that there should be no goal to remove the usb
backend from the system. The reasons are the manuals, and the CUPS
book, which only speaks about this. Also the good help at the cups
mailing lists should be mentioned, which is no longer usuable for
the customers, if we cut the usb backend off the system.
For true zero config printer, we'd need to build
up a database of
printer ids and driver mappings and include that in the distro. We also
need to make this configurable so that you have the possibility of not
doing zeroconfig printing on servers.
True. This is the first step.
I'm still asking myself how a correct paper size (Letter or DinA4)
is configured by zero conf.
If we want to extend this later, then we should think about a way to
preserve an existend, and possibly modified configuration of a specific
printer. The idea is here to get the old system configuration back,
as soon as a printer gets replugged into the system.
2) Not needing root to configure a printer
No comments from me to this topic so far.
3) Detecting when a printer is connected/disconnected
visual feedback via a notification area icon, or some other ui feedback
An easy thing to do here would be to patch cups to send out dbus signals
and both GNOME and KDE could put up tray icons or whatever. HAL could
also be used to detect disconnects reconnects
We need also handle the situation if a printer gets connected/
disconnected from the system when the system was switched off. We
should not restrict our thinking about getting signals, boot time
needs also to be handled properly.
About the tray icons: as this automatic configuration should also
work on machines without KDE nor GNOME, this is only an optional
extension in my point of view.
4) Ability to remove printers from cups (even shared
they're unplugged to prevent jobs from accumulating in the queue or being default
If we can get to zeroconfig printing we could optionally just remove a
printer from cups when its unplugged. A little more unclear how useful
it would be.
I want to point out the "optionally" here.
CUPS offers the possibility of spooling print jobs, when the
communication to a printer fails (or the admin wishes so). Sure,
Enterprise Servers admins are more interested in this spooling feature
than home users. So we should offer a configuration for both kinds of
customers. I'm thinking of storing this global configuration data
somewhere below /etc/sysconfig.
Again the points removing a printer during switch off and preserving
configuration for later replug should be possible/designed for later
SUSE LINUX Products GmbH
Maxfeldstr. 5 E-Mail: Klaus.Singvogel(a)SuSE.de
90409 Nuernberg Phone: +49 (0) 911 740530
Germany GnuPG-Key-ID: 1024R/5068792D 1994-06-27
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg)
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-factory+help(a)opensuse.org