Re: Printer driver UI [proposal]

[Chema Celorio <chema ximian com>]

	A number of people in the printing community have identified the need
to improve the user experience in this particular area that you are
describing. The main issue I see with your proposal is that you are
trying to describe how the UI is going to be layed out by the GUI
application, I don't think we want to do that but rather provide the
information to the GUI level so that it can make smart decisions as how
best to layout the interface.

	Describing the interface in the data file is going to be hard to get
right and the process to fine tune or update the interface is going to
be slow. There are just too many things to take into account, we
probably want different versions of the GUI for different levels of
complexities and I don't think we want to put that much info in such a
lower level in the chain. We might not agree how the interface is going
to look for all of the consumers of this format.

	I'd like instead for the data that something like gnome-print or
KDEPrint gets to be grouped, categorized, etc. so that we can make a
smart decision about how the GUI looks. You could say for example this
attributes are color adjustments, this are advanced options and we
should know where we want to put the widely used options (like we do
now).

	This might be a good time to also raise the issue about the limitations
that the having a PPD based print system is imposing upon us. The PPD
format was designed some time ago and we are using it for more complex
definitions. The gimp-print guys have expressed this too giving as an
example trying to specify a color correction curve on a PPD file, or how
they have to fill a range of values like options to accommodate for a
floating point setting.

regards,
Chema 


	T

On Thu, 2003-03-13 at 07:44, Michael Goffioul wrote:
> 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.