Printer driver UI [proposal]

[Michael Goffioul <goffioul imec be>]

Hi all,

This mail is intended to make a proposal concerning printer driver
user-interface, and the smooth integration of such UI into existing
graphical environment. But let me first introduce me for those who
don't know me: I'm the author and maintainer of KDEPrint, the printing
support within KDE.

Basically, the main motivation of this mail is the fact that printer
driver are getting still more complex (like gimp-print) and that 
presenting driver options to the user in a usual hierarchical way
(like in a tree view as in KDEPrint) becomes very unfriendly and
confusing when you have a lot of options. Many of those driver options
will probably never be used by a normal user so it's not needed to
show them in all cases.
IMO it could be much better for the user if we could define a framework
that could be used to describe how the driver settings should be
presented to the user. Some kind of metadata contained in the printer
driver that could be used (or not) by the graphical environment. To
illustrate my words, you can find conceptual code at:

http://printing.kde.org/downloads/ppd-parser.tar.gz

or 

http://www.geocities.com/kdeprint/ppd-parser.tar.gz

This code (for KDE/Qt) shows 3 ways of a Foomatic-3 printer driver
presentation:
	- usual hierarchical way (tree view)
	- tabbed UI using all options
	- reduced UI with additional dialogs for advanced settings
The last 2 UI are defined in the provided XML files.

My ideas up to now are the following:
- UI can be described using XML syntax, and embedded in the driver
  file (for example, PPD file) using comments. These metadata can
  the be extracted and used by a graphical environment like KDE or
  GNOME
- simple UI can  be fully described using a quite reduced XML syntax
- complex UI can be implemented in additional shared libraries, loaded
  at run-time by the environment. That way, driver developer and
  printer manufacturer could provide their own driver UI, but still
  being smoothly integrated into the environment
- in case of external UI implemented in shared libs, you can have
  different implementation for the different environment. However you
  can still imagine to embed a GNOME widget inside a KDE dialog or
  vice-versa, if we agree on a standard interface.

Please keep in mind that this is just a proposal. I'd simply like to
start a discussion on that. To know if some of you are interested in
such a development or if you find it completely useless and a waste of
time. Personally, I think there's plenty of room for UI improvement
in the Linux printing realm, but I might be the only one :-)

I tried to include all people which (I think) could be interested in
this, but I probably forgot a lot of people, because I don't know them
of I don't have their e-mail address anymore. Se feel free to forward
this mail to anyone who might be interested.

Bye.
Michael.

-- 
------------------------------------------------------------------
Michael Goffioul		IMEC-DESICS-MIRA
e-mail: goffioul imec be	(Mixed-Signal and RF Applications)
Tel:    +32/16/28-8510		Kapeldreef, 75
Fax:    +32/16/28-1515		3001 HEVERLEE, BELGIUM
------------------------------------------------------------------
This e-mail and/or its attachments may contain confidential
information.  It is intended solely for the intended addressee(s). 
Any use of the information contained herein by other persons is
prohibited.  IMEC vzw does not accept any liability for the contents
of this e-mail and/or its attachments.
------------------------------------------------------------------