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 are possiblities).
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 hal-cups-utils/hal_lpadmin tools. 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 (full automatism). 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 and offering 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 printers) when 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 here too. Best regards, Klaus. -- Klaus Singvogel SUSE LINUX Products GmbH Maxfeldstr. 5 E-Mail: Klaus.Singvogel@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@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org