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 <[EMAIL PROTECTED]> Novell, Inc. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
