On Thu, 2007-03-01 at 12:33 +0100, Klaus Singvogel wrote:
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.
Very good point. Can these detect USB devices like the usb backend? Or to they have a better canonical naming scheme for the printers?
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.
Well, it works enough to be used extensively in Fedora and Ubuntu, but yes it could be missing some pieces that we would need to add.
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...
I meant if we want to base the detection on the usb backend we'll need polling.
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.
Agreed.
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.
Locale data might be one way to guess (pretty much anyone outside North America is probably A4 :-)).
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.
Agreed.
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.
DBus signals would handle this, if there is no listener they would just be ignored, if there is a listener the listener can do whatever they want.
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.
Sounds good - we should consider a design that gets as much of the above as possible upstream as well. -JP -- JP Rosevear <jpr@novell.com> Novell, Inc. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org