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
_______________________________________________
Desktop_architects mailing list
Desktop_architects@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/desktop_architects
