Mailinglist Archive: opensuse-factory (393 mails)

< Previous Next >
Re: [opensuse-factory] Printing in openSUSE 10.3
  • From: Klaus Singvogel <kssingvo@xxxxxxx>
  • Date: Thu, 1 Mar 2007 12:33:45 +0100
  • Message-id: <20070301113345.GA5943@xxxxxxx>
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@xxxxxxx
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@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-factory+help@xxxxxxxxxxxx

< Previous Next >
Follow Ups