[Usability] Re: [Desktop_architects] Printing dialog and GNOME

[Norm Jacobs <Norm Jacobs Sun COM>]

Till Kamppeter wrote:

> Mike Shaver wrote:
>  
>
> > The requirements are probably something like "work everywhere that Firefox works, and don't suck".  
> >
> > We have a user-experience lead whom I love too much to copy on this thread, but his time is currently best spent on things other than designing our Unix printing dialog.
> >
> > Consider this an open invitation for someone to come forward with a proposal, plan, and patch for the Unix printing experience on Firefox.  It's been an under-owned area, though I think at various times Marco Pesetti, Chrises Lahey Blizzard and Aillon, and even Jody (hi!) have poked their heads in.  The Sun guys use Xprint or something with their suite builds, but I don't think supporting Xprint well is a must-have.
> >
> > I'm glad to hear that you think it's a top priority, because it will probably take quite a bit of work to get "right", given the breadth of printing and desktop configurations that we support today.
> >
> > (Please don't think that you can add a dep on libgnomeui, or even an especially-recent GTK, though, without a lot of justification and pref control.  We still have users on RH8 and 9 today, to say nothing of older Solaris setups, and for Firefox 2 at least we're not looking to break them.  Of course, a compelling case that 1997-vintage print dialogs are hurting adoption of Firefox would be, well, compelling.)
> >
> >    
>
> As it was already told earlier, Firefox/Thunderbird has different print
> dialogs plugged in for each supported OS (Win, Mac, Solaris, Linux,
> ...). I suggest to not replace the current Linux printing dialog but to
> add one. The added one can depend on CUPS and new GTK, if these
> libraries are not present (for example when building on old Red Hat) the
> old dialog is used, on current distros the new one (could be
> automatically built appropriately by checks in ./configure script).
>  
I'm inclined to agree with Till.  In general, the sooner we get applications
using the print dialogs available in the toolkits on the platform (in 
this case,
the new GTK print dialog), the better.  As Till points out, the old dialog
is still available for platforms where the toolkit doesn't provide a 
print dialog.

I do differ with Till on one point here.  The dependency should only need
to be on the toolkit.  In this case, the new GTK.  it's up to the new
GTK print dialog to use the print service interface available on the
platform (could be CUPS, could be PAPI, could be something else).

   -Norm