Mailinglist Archive: opensuse-factory (393 mails)

< Previous Next >
Re: [opensuse-factory] Printing in openSUSE 10.3
  • From: JP Rosevear <jpr@xxxxxxxxxx>
  • Date: Fri, 02 Mar 2007 18:01:03 -0500
  • Message-id: <1172876463.15633.245.camel@xxxxxxxxxxxxxxxxxxxxx>
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@xxxxxxxxxx>
Novell, Inc.

---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-factory+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-factory+help@xxxxxxxxxxxx

< Previous Next >
Follow Ups