firefox doesn't use the gnome print dialog
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Mozilla Firefox |
Fix Released
|
Wishlist
|
|||
firefox (Ubuntu) |
Fix Released
|
Wishlist
|
Mozilla Bugs |
Bug Description
The title says it all. Also, I think every app (at least in main) should use the
standard gnome dialogs (including the printing one).
In Mozilla Bugzilla #193001, Brendan-mozilla (brendan-mozilla) wrote : | #1 |
In Mozilla Bugzilla #193001, Roland-mainz (roland-mainz) wrote : | #2 |
I am not sure whether this can really be implemented without loosing existing
functionality (e.g. per-printer options and defaults) and/or rewrite parts of
both Mozilla and the Gnome Print dialog.
For Mozilla we would have at least to rewrite the current "PrinterFeatures" hack
(which is used to store the per-printer capabilities (supported "features" and
paper sizes, plex modes, resolutions, orientations, etc.)) with
nsIPrinterFeatures (e.g. a normal API instead of the prefs hack, this is bug
136058) and hook-up code to feed that information to the Gnome print dialog (and
then work around the bugs in the Gnome print dialog).
I am not sure whether spending huge amounts of work into this is wise (if you
still want to do this please consult me before starting the work) ... the
benefit isn't great and we still would not get rid of the XUL print dialog since
it is used by OS/2 and the Xlib port, too.
In Mozilla Bugzilla #193001, Otaylor-redhat (otaylor-redhat) wrote : | #3 |
- It's possible to use the gnome-print dialog and then dump a
postscript file to it. The gpdf code is an example of doing
this. So, this is generally very feasible without the
dependency on bug 192999.
- Capabilities like duplex, etc, can be queried from the
gnome-print dialog. The set of options supported by the
gnome-print dialog has a few things not supported by
mozilla so there would likely have to be a bit of extension
of the mozilla printing code for optimum integration.
The main thing I saw here was the ability to do non-collated
multiple copies. (1,1,2,2 instead of 1,2,1,2)
Cheerleading: this would be a huge win for users; unlike the
XUL dialog, the gnome-print dialog properly interacts
with CUPS on the system to list printers and be aware of the
particular options available on those printers. Plus, the
consistency would be wonderful to have.
In Mozilla Bugzilla #193001, Roland-mainz (roland-mainz) wrote : | #4 |
<email address hidden> wrote:
> - It's possible to use the gnome-print dialog and then dump a
> postscript file to it
That's not enougth for Mozilla. Last time I checked it was not possible to
disable/enable or change single items like "orientation", "print command",
"paper size" etc. dynamically (e.g. per-printer) from within Mozilla code,
something the current XUL print and print job options dialog can do. And this
and other small "nits" are requirements before the Gnome print dialog can be
used.
In Mozilla Bugzilla #193001, Otaylor-redhat (otaylor-redhat) wrote : | #5 |
What's the user feature under discussion here ... remembering your options
per-printer when selecting between multiple printers?
Obviously, different users have different requirements, but I really
can't see why remembering print options per-printer is a web-browser
required feature, as opposed to a feature that you'd like to have
in general.
(I must be using an old version of the XUL dialog, since my XUL dialog
doesn't even let me *set* the printer other than by passing options
to LPR...)
In Mozilla Bugzilla #193001, Roland-mainz (roland-mainz) wrote : | #6 |
<email address hidden> wrote:
> What's the user feature under discussion here ... remembering your options
> per-printer when selecting between multiple printers?
I wasn't thinking about that. Mozilla allows that a print driver can teach the
print dialog about what the driver within Mozilla, the printer and the site
policy supports and what not.
For example: If you have a poster printer (e.g. DIN-A0 output format) you really
do not want to allow people to print DIN-A4 on it, right ?
> Obviously, different users have different requirements, but I really
> can't see why remembering print options per-printer is a web-browser
> required feature, as opposed to a feature that you'd like to have
> in general.
See my comment above. The Gnome print dialog cannot be restricted to the set of
options supported by the driver or printer - and feeding the driver or printer
with unsupported options or invalid option combinations will only cause havoc.
Same applies to site policies - admins may want to restrict the available
options for some reason (... continuing my example above... we could buy many
many Sun workstations from the money which is currently spend for the
"accidential" DIN-A4 printouts on our DIN-A0 poster printers).
> (I must be using an old version of the XUL dialog, since my XUL dialog
> doesn't even let me *set* the printer other than by passing options
> to LPR...)
You're likely using one of the RedHat builds of Mozilla. Get an "official" build
from mozilla.org and install the Xprint RPM from http://
(don't do that on Debian/
already by default) and you'll see what I mean.
In Mozilla Bugzilla #193001, Roland-mainz (roland-mainz) wrote : | #7 |
<email address hidden>:
Instead of using the native Gnome print dialog - what about making the current
XUL print dialog more looking like the Gnome print dialog ? That would be much
easier AFAIK...
In Mozilla Bugzilla #193001, Mpgritti (mpgritti) wrote : | #8 |
> I wasn't thinking about that. Mozilla allows that a print driver can teach the
> print dialog about what the driver within Mozilla, the printer and the site
> policy supports and what not.
Printer capabilities: if I get Owen correctly the gnome print dialog already
deal with it via CUPS, no need for mozilla to worry.
Driver capabilities: if we extend mozilla postscript driver to support all gnome
print capabilities what sort of problems you expect ?
Site policy: could you point me to docs or code where the possible policies are
defined ?
I dont think it's useful to make the gnome print support all possible
combinations of mozilla drivers but rather to use one of the mozilla drivers
(postscript with an intermediate file could be the easier solution) to be able
to print through gnome print.
In Mozilla Bugzilla #193001, Martin Kretzschmar (martink) wrote : | #9 |
Owen wrote: "It's possible to use the gnome-print dialog and then dump a
postscript file to it. The gpdf code is an example of doing this."
The gpdf code was just stolen from Chris Lahey's galeon patch from Ximian Desktop 2.
I can't remember adding anything interesting on top of that in the gpdf
gnome-print dialog code.
In Mozilla Bugzilla #193001, Dvschweiger (dvschweiger) wrote : | #10 |
(In reply to comment #3)
> - Capabilities like duplex, etc, can be queried from the
> gnome-print dialog. The set of options supported by the
> gnome-print dialog has a few things not supported by
> mozilla so there would likely have to be a bit of extension
> of the mozilla printing code for optimum integration.
> The main thing I saw here was the ability to do non-collated
> multiple copies. (1,1,2,2 instead of 1,2,1,2)
XPrint supports duplex, simplex, etc, from the Mozilla print dialog. What is the
gain here?
> Cheerleading: this would be a huge win for users; unlike the
> XUL dialog, the gnome-print dialog properly interacts
> with CUPS on the system to list printers and be aware of the
> particular options available on those printers. Plus, the
> consistency would be wonderful to have.
CUPS, LPRng, etc, are supported by XPrint, too. Again what is the gain here?
In Mozilla Bugzilla #193001, Dvschweiger (dvschweiger) wrote : | #11 |
(In reply to comment #8)
> Driver capabilities: if we extend mozilla postscript driver to support all gnome
> print capabilities what sort of problems you expect ?
Extending the mozilla postscript driver is useless, many Linux distributions
already build without it and they do not care about that code - too buggy, too
insecure. XPrint printing has proven to be the better print solution
In Mozilla Bugzilla #193001, Mpgritti (mpgritti) wrote : | #12 |
The target of this bug, together with 192999, is to integrate mozilla printing
with gnome-print. Gnome print is composed of a frontend (libgnomeprintui) and a
backend (libgnomeprint). To be able to use the dialog (and his functionalities,
it's not just matter of look and feel) you have to use the backend to do the
actual print.
Now there are two ways to use this backend. Dump it a poscript file or add
gfx/src/gnomeprint (bug 192999).
Using the native dialog you gain consistent look and feel, consistent
interaction, functionalities (for example proper interaction with CUPS owen
mentioned)
In Mozilla Bugzilla #193001, Chofmann (chofmann) wrote : | #13 |
any chances of getting something working by 1.8a?
In Mozilla Bugzilla #193001, Roland-mainz (roland-mainz) wrote : | #14 |
chris hofmann wrote:
> any chances of getting something working by 1.8a?
Not unless the Gnome print dialog itself gets some enhanchements. It's still a
far far way from integrating it into Mozilla without loosing lots of
functionality.
In Mozilla Bugzilla #193001, Roland-mainz (roland-mainz) wrote : | #15 |
<email address hidden> wrote:
> Using the native dialog you gain consistent look and feel, consistent
> interaction, functionalities
What do you want exactly ? Working, usefull functionality or a "consistent look
and feel" where half the functionality is not working ?
> (for example proper interaction with CUPS owen mentioned)
What about platforms or Linux distributions which do not use CUPS ? Do you just
"ignore" them with the comment "you have to use CUPS" or will you support them,
too ?
In Mozilla Bugzilla #193001, Roland-mainz (roland-mainz) wrote : | #16 |
<email address hidden> wrote:
> > I wasn't thinking about that. Mozilla allows that a print driver can teach
> > the
> > > print dialog about what the driver within Mozilla, the printer and the
> > site policy supports and what not.
>
> Printer capabilities: if I get Owen correctly the gnome print dialog already
> deal with it via CUPS, no need for mozilla to worry.
Erm... what about platforms which do not have CUPS ? And the way how CUPS
handles the way is very very incomplete.
> Driver capabilities: if we extend mozilla postscript driver to support all
> gnome print capabilities what sort of problems you expect ?
See David Schweigers's comment #11 about the mozilla postscript driver. I am not
sure whether it is a bright idea to extend that code and wallpaper another "fix"
on top of it. I already said a couple of _years_ (at least two years per bug
119491 comment #15) ago that the the postscript print module has very serious
design problems and should be re-done from scratch.
And nothing changed since that except braindead wallpapering over bugs.
> Site policy: could you point me to docs or code where the possible policies
> are defined ?
I mean "site policies" as described in the original CDEnext docs (they're based
on the ISO print stuff) - basically you have a way to restrict, extend or
override certain printer attributes without the need to change the printer
description (such as a PPD). A basic example is to have a rule which defines
that a certain set of printers is only allowed to print DIN-A4 in the main tray
(and the user cannot override that locally - the rules are set on the server
side).
> I dont think it's useful to make the gnome print support all possible
> combinations of mozilla drivers but rather to use one of the mozilla drivers
> (postscript with an intermediate file could be the easier solution) to be able
> to print through gnome print.
There is the "minor" problem that Xprint doesn't output PostScript files (unless
you print to a file), the jobs are generated on the Xprint server side (which
can be on another box) - the local application don't see any PostScript data at
all (which is very usefull for applications running on handhelds since all the
heavywheight stuff is done on the server side).
In Mozilla Bugzilla #193001, Mpgritti (mpgritti) wrote : | #17 |
> What do you want exactly ? Working, usefull functionality or a "consistent look
> and feel" where half the functionality is not working ?
I want mozilla to support the limited set of functionalities of the GNOME print
system, I dont need more than that. If gnome print doesnt support a feature
there is not much value for GNOME users to have it available in the browser
(unless it's a browser specific feature).
It's more important to be able to interact consistently with the print system.
Right now we are using two different print systems in GNOME and mozilla. That
cause differences in the user interface and, more importantly, it adds
complexity to the conceptual model the user build about the desktop print
system. That's a learning cost for the majority of GNOME users, while CDEnext
site policies would be useful to a minority (and what would they gain anyway if
mozilla is the only desktop application to support them ?).
> What about platforms or Linux distributions which do not use CUPS ? Do you just
> "ignore" them with the comment "you have to use CUPS" or will you support them,
> too ?
I'm not advocating to discontinue xprint support or the XUL dialog,
distributions that likes can continue to use it.
I just want using gnome printing system to be one of the options. Ideally we
would support libgnomeprint as backend and libgnomeprintui as frontend. Though
libgnomeprint drawing api is probably going to be deprecated (see
http://
waste of time.
On the long time the situation is pretty clear to me. GNOME and mozilla should
be able to use the same drawing api (Cairo?). (Obviously mozilla could continue
to support different backends if desired). Then supporting the remaining part of
libgnomeprint(ui) would be easy.
On the short time we can just try to hide the print system differences to the user:
1 reimplementing libgnomeprintui dialog in XUL
2 using libgnomeprint just as a transport mechanism and libgnomeprintui native
dialog.
In any case I think the libgnomeprintui GUI should be split in a setup and a
print part. That seem more sane and would integrate better with mozilla. I'll
see if I can get someone to do it.
To me the pro of 2 are:
- we start to work on an unified user interface, rather then maintaining a fork
and having to sync it
- we are using gnome print for most of the work so it would probably result in
better integration
- we get nearer to the long term goal, only drawing api is left
The con is that we would have to use the postscript backend, which is apparently
a mess.
I think 1.8a target is not realistic unfortunately. I propose to approach the
problem this way.
1 Separate print and setup in libgnomeprintui
2 Make a list of the remaining incosistencies between XUL and native dialog
3 See if it's possible to fix these and how much work would be compared to use
the native dialog
I can deal with 1 and 2. I'll probably need some help on 3.
In the mean time we should really look at using a common drawing api on the long
run. I'd open a bug about it and cc GNOME/mozilla maintainers.
At the moment gnome printing system is not fully defined. That's a...
In Mozilla Bugzilla #193001, Mpgritti (mpgritti) wrote : | #18 |
> There is the "minor" problem that Xprint doesn't output PostScript files (unless
> you print to a file), the jobs are generated on the Xprint server side (which
> can be on another box) - the local application don't see any PostScript data at
> all (which is very usefull for applications running on handhelds since all the
> heavywheight stuff is done on the server side).
I fear we are still not on the same page here, probably my fault in explaining
it. What I ideally want is:
--enable-xprint
--enable-gnomeprint
When gnomeprint is enabled we could also use the native print dialog, when
xprint is enabled we would use the XUL one.
I dont think there is interest to make libgnomeprintui a generic dialog that can
be used by different print systems.
In Mozilla Bugzilla #193001, Christian Biesinger (cbiesinger) wrote : | #19 |
(In reply to comment #18)
> When gnomeprint is enabled we could also use the native print dialog, when
> xprint is enabled we would use the XUL one.
what if both are enabled? or is that not possible?
In Mozilla Bugzilla #193001, Chofmann (chofmann) wrote : | #20 |
yeah, I guess one question is could both printing dialogs, and backends be
available a runtime and enabled via a pref (hidden?). That would allow both
distributors and users to make the selection about what printing features they
need until we get both to the state of comparable features.
I'm pretty sure that for the linux desktop get wide enterprise and business
deployment things page orientation (portrait and landscape) and paper size
controls are going to be required. Mozilla and open office are going to need
that feature for producing spreadsheets, wide tables, powerpoint like preso's
and legal docs. We need to figure out how to get those on the gnome roadmap if
they aren't there now.
it would be great if someone could go down the list of features available in the
XUL based print dialog, the gnome print dialog, the open office print dialog,
and maybe m$ office print dialogs to make sure the gnome print dialog and
supporting backend is on track all the competive features it needs if it doesn't
have them already...
I think it would be really helpful to have a clear view of that to move forward
and an accurate and up to date chart might look something like...
page orientation x
page size x
feature c
feature d
...
...
can someone volenteer to put that together with some of the data that is
scattered among the comments in this bug and a look at the latest versions?
In Mozilla Bugzilla #193001, Mpgritti (mpgritti) wrote : | #21 |
(In reply to comment #20)
> yeah, I guess one question is could both printing dialogs, and backends be
> available a runtime and enabled via a pref (hidden?). That would allow both
> distributors and users to make the selection about what printing features they
> need until we get both to the state of comparable features.
Yeah, that sounds feasible to me.
> moz-xul gnome open-office office
>
> page orientation x
> page size x
> feature c
> feature d
> ...
> ...
>
> can someone volenteer to put that together with some of the data that is
> scattered among the comments in this bug and a look at the latest versions?
Yeah, I'll see what I can do. In general I dont expect gnome print to lack
important features and I'm sure we can put them on GNOME roadmap if there are.
What worries me most atm is the drawing api business, but let's deal with things
one at a time.
In Mozilla Bugzilla #193001, Chofmann (chofmann) wrote : | #22 |
thanks marco. does anyone know what evolution uses? the UI seems to have a
pretty broad/good set of UI printing features along the lines that apps like
mozilla and OO might need.
In Mozilla Bugzilla #193001, Mpgritti (mpgritti) wrote : | #23 |
Evolution uses gnome print. (Other apps that use gnome print are gnumeric and gedit)
In Mozilla Bugzilla #193001, Roland-mainz (roland-mainz) wrote : | #24 |
<email address hidden> wrote:
> > What do you want exactly ? Working, usefull functionality or a "consistent
> > look and feel" where half the functionality is not working ?
>
> I want mozilla to support the limited set of functionalities of the GNOME
> print system,
> I dont need more than that. If gnome print doesnt support a feature
> there is not much value for GNOME users to have it available in the browser
> (unless it's a browser specific feature).
The Gnome print dialog can easily be extended to match the current features in
the Mozilla XUL/CDEnext/Windows dialogs... that's not hard... :)
I am willing to cooperate here and help marco with some specs etc. to make the
Gnome print dialog more flexible (e.g. that it can support more than one print
system - the CDEnext and KDE print dialogs are already able to do that since
years...).
> Right now we are using two different print systems in GNOME and mozilla. That
> cause differences in the user interface and, more importantly, it adds
> complexity to the conceptual model the user build about the desktop print
> system. That's a learning cost for the majority of GNOME users, while CDEnext
> site policies would be useful to a minority (and what would they gain anyway
> if mozilla is the only desktop application to support them ?).
The site policies (and other features like autoconfiguration) aren't
CDEnext-specific, they are coming from the Xprint side (most of the major design
documents about Xprint were written for the CDEnext project so please forgive me
when I start to mix both terms here wildly), so far this means Mozilla, Motif2,
Lesstif, OO and Qt-based applications can employ these features.
[snip]
> On the long time the situation is pretty clear to me. GNOME and mozilla should
> be able to use the same drawing api (Cairo?). (Obviously mozilla could
> continue to support different backends if desired)
Well, there is actually no need to make an extra Cairo _backend_ (we may better
put it somewhere in the _middle_ :) ... the Xprint server side supports the
OpenGL API and allowes to plug-in PostScript code fragments, too - so either
native Cairo--
plugins) which need it can generate PostScript code fragments (assuming the
destination PDL allows PS embedding, otherwise the OpenGL path should be used
(which is better anyway since it can support transparency)).
> Then supporting the remaining part of libgnomeprint(ui) would be easy.
>
> On the short time we can just try to hide the print system differences to the
> user:
>
> 1 reimplementing libgnomeprintui dialog in XUL
> 2 using libgnomeprint just as a transport mechanism and libgnomeprintui native
> dialog.
[1] is much easier for now, otherwise we will have do deal with the internals of
the mozilla print settings system and that's something which can cause _lots_ of
bugs - the code has become an horrible minefield and doing changes there usually
requires testing against the last 10 closed bug reports in that area... ;-(
BTW: When touching the XUL print dialog we have to sync with the OS/2 people
since they use the dialog, too.
> In any case I think the libgnomepr...
In Mozilla Bugzilla #193001, Chofmann (chofmann) wrote : | #25 |
Created an attachment (id=148229)
xul/gnome/office feature comparison
In Mozilla Bugzilla #193001, Roland-mainz (roland-mainz) wrote : | #26 |
chris hofmann wrote:
> Created an attachment (id=148229)
> xul/gnome/office feature comparison
That chart is incomplete. The Mozilla XUL dialog has "plex mode" ("simplex",
"duplex", "tumble" and custom attributes), "paper source" and "find printerr"
capabilities when Xprint is used ("orientation" is in available in the "page
setup" dialog).
In Mozilla Bugzilla #193001, Roland-mainz (roland-mainz) wrote : | #27 |
Created an attachment (id=148236)
Mozilla-
Updated chart, on demand I can add CDEnext and KDE dialogs, too.
In Mozilla Bugzilla #193001, Mpgritti (mpgritti) wrote : | #28 |
> > In any case I think the libgnomeprintui GUI should be split in a setup and a
> > print part. That seem more sane and would integrate better with mozilla. I'll
> > see if I can get someone to do it.
See the comparation chart. Some features in mozilla are in the Page Setup
dialog, and they are in the Print dialog for gnome print. That's an incosistency
we need to deal with.
In Mozilla Bugzilla #193001, Piers Cornwell (piers-gnome) wrote : | #29 |
Screenshots of various print dialogs for Firefox/Win, Mozilla/Linux, Internet
Explorer/Win and Gnumeric (libgnomeprint[
In Mozilla Bugzilla #193001, Mpgritti (mpgritti) wrote : | #30 |
> The Gnome print dialog can easily be extended to match the current features in
> the Mozilla XUL/CDEnext/Windows dialogs... that's not hard... :)
> I am willing to cooperate here and help marco with some specs etc. to make the
> Gnome print dialog more flexible (e.g. that it can support more than one print
> system - the CDEnext and KDE print dialogs are already able to do that since
> years...).
It sounds reasonable to work on a more complete design of the dialog. (I may try
to get a proper usability review on it while I'm at it too). libgnomeprintui
dialog seem to be bound to libgnomeprint (it requires a GnomePrintJob). So, in
my limited knowledge, it's not possible to make it support multiple backends.
Though there is apparently some interest in having a dialog in gtk itself
(generic user interface only).
http://
Maybe that's the way to go. Anyway I'll try to work on a design and figure out
if we can make it independent from the backend.
> Well, there is actually no need to make an extra Cairo _backend_ (we may better
> put it somewhere in the _middle_ :) ... the Xprint server side supports the
> OpenGL API and allowes to plug-in PostScript code fragments, too - so either
> native Cairo--
> plugins) which need it can generate PostScript code fragments (assuming the
> destination PDL allows PS embedding, otherwise the OpenGL path should be used
> (which is better anyway since it can support transparency)).
Xprint is interesting to me only if we can adopt it as a common print system for
GNOME/Mozilla. I noticed it's now hosted at freedesktop.org, there has been
already discussions about adopting it in GNOME? What's the situation with KDE,
is it one of the supported backends, the only one?
Sorry, I need to be educated, print isnt quite my field;)
mon (javiermon-deactivatedaccount) wrote : | #31 |
The title says it all. Also, I think every app (at least in main) should use the
standard gnome dialogs (including the printing one).
In Mozilla Bugzilla #193001, Leon-sha (leon-sha) wrote : | #32 |
Printing support was added in GTK+ 2.10.
The API Reference Manual is here.
http://
Seems it has a relationship with cairo.
Can we start to implemente this on cairo based mozilla?
In Mozilla Bugzilla #193001, Leon-sha (leon-sha) wrote : | #33 |
I have just tried the Gtk Print API in gtk+2.10.
It is quite simple and cool. An example can be found here.
http://
There are two ways to impletement this in mozilla.
1. Just use the GTK Print API dialog part.
http://
It's maybe simple to do. But I don't think it is a right way.
2. Use the GTK Print high level API
http://
It may be need a big change in mozilla.
In Mozilla Bugzilla #193001, Ghee-teo (ghee-teo) wrote : | #34 |
Now that GNOME printing support have progressed moving from lingnomeprint[ui] to
GTK+, is it time know to reconsider this RFE?
The new GTK+ printing API as listed by Leon Sha now provides a set of printing
commands with pango/cairo rendering supports should address the following problems:
- GTK+, a common toolkit layer for Mozilla/
- A Print Dialog that is fairly complete and provided hook for customization
- A CUPS backend already in place, and folks at Sun is working on a PAPI (Printing API of OpenStandard, http://
backend
Benefits of RFE:
- consistent user experiences on printing dialog across gtk+ based apps [1]
- proper interaction with CUPS/PAPI systems [2]
- Better interaction with CUPS/PAPI backends allow better interaction with addition of new printer or browsing of printers.
Pros:
- site policies restrictions still need to be addressed.
So what do you think?
[1] Okay. This may take a while for many of the gtk+ apps to adopt the new dialog and API, but that is the goal :)
[2] This is pretty extensible, so it can be more backend in the future.
In Mozilla Bugzilla #193001, Dar (darren-kenny) wrote : | #35 |
I would like to add my voice to this too.
While I undestand the original evaluation, as Ghee mentioned, there has been a re-architecture of the printing situation in GTK+ - enough to warrant a re-evaluation at least.
Is there anyone from the Mozilla side that could look into this?
Thanks,
Darren.
Changed in firefox: | |
assignee: | ijackson → nobody |
Changed in firefox: | |
status: | Unconfirmed → Confirmed |
In Mozilla Bugzilla #193001, Martin Meyer (elreydetodo) wrote : | #36 |
There was a HOWTO sent recently to Gnome's desktop-devel list for migrating to the GTK+ print dialog. It gives some pretty good instructions for migrating to the new dialog, and I'm sure the Gnome people would be willing to help get this done if anyone asked. The message/HOWTO can be found at:
http://
Sebastian Urban (surban) wrote : | #37 |
For many people this is a critical problem! This is one of the reasons, why many people switch back to Windows! Printing on Linux is still terrible. It's a shame that the default installed browser is not able to integrate into the desktop environment! We have to do something about that.
Same for OpenOffice, but the print dialog in OpenOffice is much better than Firefox's.
Is somebody working on it? Pherhaps I will see, what I can do...
Sebastian Urban (surban) wrote : | #38 |
Link to Mozilla Bugzilla: https:/
John Vivirito (gnomefreak) wrote : | #39 |
This is not a critical issue, but we will get to it asap.
Changed in firefox: | |
assignee: | nobody → mozilla-bugs |
status: | Confirmed → Needs Info |
Changed in firefox: | |
status: | Unknown → Confirmed |
In Mozilla Bugzilla #193001, Kherron+mozilla (kherron+mozilla) wrote : | #40 |
Created an attachment (id=289155)
Work in progress - GTK+ print dialog
Work in progress. This displays the GTK+ print dialog instead of the built-in XUL dialog for print requests. It's pretty rough; for example, after dismissing the dialog it crashes while trying to read back the paper size (and there's no place to select a paper size within the dialog).
In Mozilla Bugzilla #193001, Ghee-teo (ghee-teo) wrote : | #41 |
hmm, paper size typically is loaded by the backend support library from the PPD file I think. How is the existing XUL dialog get its list of available paper size?
Keep up the Good work!
In Mozilla Bugzilla #193001, Kherron+mozilla (kherron+mozilla) wrote : | #42 |
Created an attachment (id=292223)
Updated work in progress
This still doesn't work. Apparently I'm not doing either cairo or glib refcounting correctly. However, it includes code both to display the GTK print dialog, and to use the GTK printing system to create the print job, instead of working directly with PS/PDF and CUPS.
In Mozilla Bugzilla #193001, Ventnor-bugzilla (ventnor-bugzilla) wrote : | #43 |
Kenneth, are you still actively working on this?
In Mozilla Bugzilla #193001, Kherron+mozilla (kherron+mozilla) wrote : | #44 |
(In reply to comment #39)
> Kenneth, are you still actively working on this?
I've been busy lately. I have some vacation time coming up, and I hope to make some more progress on this. I wouldn't turn down some help, though.
In Mozilla Bugzilla #193001, Kherron+mozilla (kherron+mozilla) wrote : | #45 |
Created an attachment (id=294038)
Work in progress #3
The previous patch wasn't working because it was taking a cairo surface created by the gtk printing code and manipulating it through thebes. Libgtk was using the system's version of cairo, while thebes uses the copy that's built in to gecko. It seems that approach won't be feasible for the time being.
This patch prints through gtk the the same way we print through other printing systems. It writes the print job to a temporary file and then prints that. I have only tested with print-to-file, but it seems to work properly, including the ability to select PDF or PS. There's still no way to select a paper size from the print dialog.
In Mozilla Bugzilla #193001, Ventnor-bugzilla (ventnor-bugzilla) wrote : | #46 |
Created an attachment (id=296080)
Patch
Kenneth, is it OK if I post my patch? It is a continuation of your WIP #3 and I have been working on it full-time as part of my internship.
All of the Firefox-centric options have been moved to the print dialog in a custom tab ported to GTK. This allows us to use the native Page Setup dialog as well which allows us to use all the quirky GTK page sizes and margins. Everything seems to work OK.
The reason the majority of the dialog code is in widget/ and not embedding/ is that printingui/
In Mozilla Bugzilla #193001, Roc-ocallahan (roc-ocallahan) wrote : | #47 |
+#ifndef __gen_nsIPrintS
+#define __gen_nsIPrintS
Identifiers with two leading underscores are reserved for the compiler
+#ifndef __gen_nsIPrintS
+#include "nsIPrintSession.h"
+#endif
Don't wrap #includes like this, it's pointless
+/* Use this macro when declaring classes that implement this interface. */
+#define NS_DECL_
+ virtual void SetNativePageSe
+ virtual void SetNativePrintS
+ virtual void SetNativePrinte
+ virtual GtkPageSetup *GetNativePageS
+ virtual GtkPrintSettings *GetNativePrint
+ virtual GtkPrinter *GetNativePrint
Don't need this macro, this is only one implementation of the interface
+// If you add any here remember to set them to NULL in Show()
+static GtkWidget* radio_as_laid_out;
+static GtkWidget* radio_selected_
+static GtkWidget* radio_separate_
+static GtkWidget* shrink_
+static GtkWidget* print_bg_
+static GtkWidget* print_bg_
+static GtkWidget* selection_
+static GtkWidget* header_
+static GtkWidget* header_
+static GtkWidget* header_
+static GtkWidget* footer_
+static GtkWidget* footer_
+static GtkWidget* footer_
Put all these plus the static functions into a real object with fields, methods and a destructor
+static nsresult ImportSettings(
+static nsresult ExportSettings(
Write parameter names
+static GtkWindow *
+get_gtk_
This function must already exist in nsWindow, use that
+static void
+moz_destroy_
+{
+ char* custom_
+
+ custom_
+ if (custom_
+ g_free(
Don't do this, just use g_object_
+static char*
+moz_convert_
+{
+ switch (gtk_combo_
+ case 1:
+ return "&T";
+ case 2:
Don't use magic numbers for the header/footer types, use an enum. And have an array with the tags, e.g.
static const char headerFooterTag
+ nsDependentString currStrWrapper = nsDependentStri
+ if (currStrWrapper
+ gtk_combo_
+ else if (currStrWrapper
+ gtk_combo_
You can use the headerFooterTags array here with a loop.
+ GtkWidget* prompt_dialog = gtk_dialog_
Create a helper class derived from NS_ConvertUTF16
+ gtk_box_
In Mozilla Bugzilla #193001, Roc-ocallahan (roc-ocallahan) wrote : | #48 |
There's a whole lot of code that should be checking nsresults in the Import and Export functions.
+ else if (nsDependentCSt
Use stricmp
+static inline void
Don't make functions "static inline void", just "static", the compiler will do the right thing
+ nsCAutoString gtkPrinter;
+ CopyUTF16toUTF8
I think you can just write
NS_ConvertUTF
+ offset = 5;
Too magical, write NS_ARRAY_
+ nsAutoString nmPrinter;
+ CopyUTF8toUTF16
Just use NS_ConvertUTF8t
+ nsCAutoString geckoPaper;
+ CopyUTF16toUTF8
Similar here
+ nsAutoString name;
+ CopyUTF8toUTF16
+ aNS->SetPaperNa
ditto
+ if (szFromSettings)
+ gtk_paper_
Makes more sense to have "if (szPaper)"
+ if (lstRanges[
+ if (lstRanges[ii].end < end) end = lstRanges[ii].end;
Just use "start = PR_MIN(...); end = PR_MAX(...);"
+ GtkPageRange* lstRanges(
+ &ctRanges));
Use = instead of copy construction
Is it true that when ctRanges is 0, we don't need to free lstRanges?
nsPrintJobGtkGTK is a horrible name. Let's just call it nsPrintJobGTK.
struct PrintJobGtkDone is probably overkill, you could use a static function for the callback and just the nsILocalFile* for the callback data, just NS_RELEASE it. You'll have to get the nsCOMPtr to forget it to keep the refcounts balanced.
So there's no way to share these strings with other print dialog implementations?
In Mozilla Bugzilla #193001, c7d2f5c8667d26fffd5e7772d632c76d (c7d2f5c8667d26fffd5e7772d632c76d-deactivatedaccount) wrote : | #49 |
(In reply to comment #43)
> +/* Use this macro when declaring classes that implement this interface. */
> +#define NS_DECL_
> + virtual void SetNativePageSe
> + virtual void SetNativePrintS
> + virtual void SetNativePrinte
> + virtual GtkPageSetup *GetNativePageS
> + virtual GtkPrintSettings *GetNativePrint
> + virtual GtkPrinter *GetNativePrint
>
> Don't need this macro, this is only one implementation of the interface
It's the only implementation of this interface in the moz tree, but that doesn't mean you shouldn't provide the macro! (E.g. epiphany might want to implement that interface in its own print session class.)
In Mozilla Bugzilla #193001, Kherron+mozilla (kherron+mozilla) wrote : | #50 |
(In reply to comment #42)
> Kenneth, is it OK if I post my patch? It is a continuation of your WIP #3 and I
> have been working on it full-time as part of my internship.
Michael, that's fine. It's clear you can spend more time on this than I can. It's nice to see Mozilla expend some resources on this.
My next change would have been to have the GtkPrinter, GtkPrintSettings, &
GtkPageSetup be owned by the nsIPrintSettings object instead of the
nsIPrintSession. Gecko supports printing without displaying a print dialog
first, so the code must be able to construct the GTK objects from the gecko
print settings and then use them to print. This would also simplify saving &
loading a serialized GtkPrintSettings when the nsIPrintSettings object is saved
or loaded from prefs.
In Mozilla Bugzilla #193001, Shaver (shaver) wrote : | #51 |
(In reply to comment #43)
> +#ifndef __gen_nsIPrintS
> +#define __gen_nsIPrintS
>
> Identifiers with two leading underscores are reserved for the compiler
I suspect he was just following the pattern used by xpidl in its generated headers, misleading though its example may be.
In Mozilla Bugzilla #193001, Ventnor-bugzilla (ventnor-bugzilla) wrote : | #52 |
Created an attachment (id=296434)
Patch 2
This patch is a doozy. It implements nsIPrintettingsGTK for storing native data thus allowing silent printing to work with sane defaults, since defaults are in the constructor. A lot of dialog construction code was abstracted out, and the device context spec code was just about rewritten to become completely dependent upon the GTK print API.
This probably means that CUPS no longer holds a monopoly on our Linux print service (yay!) but it means breaking things for poor bz again :( I included code to return early in the event of an old GTK version so we gracefully fail instead of crash.
This also means that nsPrintJobGTK and nsPrintJobFacto
In Mozilla Bugzilla #193001, c7d2f5c8667d26fffd5e7772d632c76d (c7d2f5c8667d26fffd5e7772d632c76d-deactivatedaccount) wrote : | #53 |
Without a screenshot it's hard to tell what's going on, but I think you have all the spacings and paddings wrong, and you're not setting the combos as menmonic targets of the labels (actually, you don't even have mnemonics on the strings).
+ char* custom_string = ToNewCString(
+ g_object_
ToNewCString is not compatible with g_free.
+#if GTK_CHECK_
+ | GTK_PRINT_
+#endif
I don't see code anywhere in the print engine to handle n-up printing?
+ mPrinter = gtk_printer_
+ gtk_printer_
+ gtk_printer_
Erm... g_object_ref (rhs.mPrinter) ?
---
Will this patch interfere in any way with gtk-based embedders that use the "PostScript/
In Mozilla Bugzilla #193001, Ventnor-bugzilla (ventnor-bugzilla) wrote : | #54 |
I believe the padding is right, since a lot of those values were borrowed from Epiphany's glade files. It looks correct to me.
In Mozilla Bugzilla #193001, Roc-ocallahan (roc-ocallahan) wrote : | #55 |
+// If you add any here remember to set them to NULL in Show()
+static GtkWidget* radio_as_laid_out;
+static GtkWidget* radio_selected_
+static GtkWidget* radio_separate_
+static GtkWidget* shrink_
+static GtkWidget* print_bg_
+static GtkWidget* print_bg_
+static GtkWidget* selection_
+static GtkWidget* header_
+static GtkWidget* header_
+static GtkWidget* header_
+static GtkWidget* footer_
+static GtkWidget* footer_
+static GtkWidget* footer_
I asked for these (plus the static functions that use them) to be made fields of a C++ object. That object should also store a reference to the string bundle so we don't have to get it more than once. moz_get_
+ if (index == 6)
Make a #define CUSTOM_
Also, assert that index <= CUSTOM_
+ if (gtk_combo_
Use #defined value
+ gtk_editable_
why - 1?
+ g_object_
free, not g_free
+ for (int i = 0; i < 7; i++) {
NS_ARRAY_
+ for (int i = 0; i < 6; i++) {
NS_ARRAY_
Instead of currStrWrapper, use strcmp to compare with currentString and use strdup to copy the string.
moz_construct_
rv checking is still missing.
+ mPageSetup = NULL;
+ }
+ if (mPrintSettings) {
+ g_object_
+ mPrintSettings = NULL;
+ }
+ if (mPrinter) {
+ g_object_
+ mPrinter = NULL;
No need to null these out in the destructor.
+hfBlank=--blank--
+hfTitle=Title
+hfURL=URL
+hfDate=Date/Time
+hfPage=Page #
+hfPageTotal=Page # of #
+hfCustom=Custom...
+customPrompt=
Make these more meaningful for localizers --- expand "hf" to headerFooter, and customHeaderFoo
Christian, I think this should be good for GTK embedders ... you just have to call nsIPrintOptions
In Mozilla Bugzilla #193001, Ventnor-bugzilla (ventnor-bugzilla) wrote : | #56 |
Created an attachment (id=296476)
Patch 3
Addresses remaining review comments, hopefully.
In Mozilla Bugzilla #193001, Roc-ocallahan (roc-ocallahan) wrote : | #57 |
I guess there is a problem, which is that old code that set up the nsIPrintSettings to e.g. print to file via the printToFile attribute and toFileName attribute, will no longer work. So a lot of those attributes need to be reimplemented in nsPrintSettingsGTK to read and write the Gtk objects.
In Mozilla Bugzilla #193001, Roc-ocallahan (roc-ocallahan) wrote : | #58 |
In fact, nsPrintSettingsGTK should perhaps not extend nsPrintSettings, since we're changing the implementation to store most of its data in Gtk objects instead of fields of the nsPrintSettings class.
In Mozilla Bugzilla #193001, c7d2f5c8667d26fffd5e7772d632c76d (c7d2f5c8667d26fffd5e7772d632c76d-deactivatedaccount) wrote : | #59 |
(In reply to comment #53)
> I guess there is a problem, which is that old code that set up the
> nsIPrintSettings to e.g. print to file via the printToFile attribute and
> toFileName attribute, will no longer work. So a lot of those attributes need to
> be reimplemented in nsPrintSettingsGTK to read and write the Gtk objects.
Epiphany uses exactly this method to print (print-to-file, then process itself), so this would be a problem for us.
(In reply to comment #50)
> I believe the padding is right, since a lot of those values were borrowed from
> Epiphany's glade files. It looks correct to me.
(I assume you _want_ to make this dialogue HIG compliant? If not, disregard the following.)
It doesn't look correctly to me.
- the labels are missing mnemonics.
- the spacings and paddings are wrong. In fact, you should almost never have to use paddings if you set up the spacings and border widths correctly (except the paddings in the GtkAlignments).
Could you make a screenshot of the custom tab?
In Mozilla Bugzilla #193001, Ventnor-bugzilla (ventnor-bugzilla) wrote : | #60 |
Created an attachment (id=297068)
Patch 4
This will give the labels mnemonics and will move a lot of settings transfer code from nsPrintDialogGTK to nsPrintSettingsGTK, so that when you set something with one of the nsPrintSettings functions, the internal GTK object is updated too so it is reflected in the GTK print job.
Print-to-file has moved back to manual handling for embedders.
In Mozilla Bugzilla #193001, Roc-ocallahan (roc-ocallahan) wrote : | #61 |
Seems like you can get rid of all the Import... and Export... functions by relying on nsPrintSettings
In Mozilla Bugzilla #193001, Roc-ocallahan (roc-ocallahan) wrote : | #62 |
[more offline discussion]
We'll maintain our own outputFormat variable. That just tells us whether to override GTK's idea of what the format should be when we finally do the printing.
We'll also keep our own printToFile variable. There doesn't seem to be a foolproof way to tell GtkPrintSettings to print to a file. However, it looks like we can store the file name in the print settings, so we should.
Thus, most of ExportPrintToFile (the file name parts) will move to nsPrintSettings
You should document in nsPrintSettingsGTK which variables we're storing for ourselves and explain that for the rest, the Gtk objects contain "the truth".
+ case GTK_PRINT_
+ // map this to selection for now
I think this should probably map to the first page or something.
In Mozilla Bugzilla #193001, Ventnor-bugzilla (ventnor-bugzilla) wrote : | #63 |
Created an attachment (id=297114)
Patch 5
Please be the last one; no more comments...
In Mozilla Bugzilla #193001, Roc-ocallahan (roc-ocallahan) wrote : | #64 |
"Print selection" should be a boolean field of nsPrintSettingsGTK, meaning "override the page ranges and just print the selection". Don't forget to initialize the dialog properly using that field.
ExportPageRange mostly isn't needed. Let's keep the page ranges in the GTK object and extract them from GetStartPageRan
if (gtk_toggle_
+ geckoPages = nsIPrintSetting
Store the value of this toggle in nsPrintSettingsGTK. Then when someone calls GetPrintRange, compute the nsIPrintSetting
+ PRUnichar* header_
+
+ aSettings-
+ aSettings-
+ aSettings-
These are leaking, right?
+ aSettings-
+ aSettings-
+ aSettings-
Same here.
Need to break lines at 80 chars.
+void
+nsPrintDialogW
+{
+ aNS->SetOutputF
Why do this? We should leave the output format alone.
+ // Is this print-to-file?
+ if (gtk_print_
+ aNS->SetPrintTo
+ return;
+ }
Why do this? I don't think this is needed. GetPrintToFile should just return the "print to file override" set by SetPrintToFile. This may not even be correct if our own code sets GTK_PRINT_
+ aNS->SetPrintTo
Don't do this either.
+ aNS->SetPrinter
And don't do this, the settings' internal GTK object is already correct!
+ // Now newPageSetup has a refcount of 2 (SetGtkPageSetup will addref), put it to 1 so if
+ // this gets replaced we don't leak.
+ g_object_
Don't we need to unref gtkSettings as well?
+ switch (format) {
+ case nsIPrintSetting
+ surface = new gfxPDFSurface(
+ break;
+ case nsIPrintSetting
+ surface = new gfxPSSurface(
+ break;
+ case nsIPrintSetting
+ default:
+ {
+ nsCOMPtr<
+ if (mToPrinter) {
+ GtkPrinter* thePrinter;
+ printSettingsGT
+ if (gtk_printer_
+ surface = new gfxPDFSurface(
+ else
+ surface = new gfxPSSurface(
+ } else {
+ GtkPrintSettings* theSettings;
+ printSettingsGT
+ const gchar* fmtGTK = gtk_print_
+ if (!fmtGTK) // This can be null, ...
In Mozilla Bugzilla #193001, Ventnor-bugzilla (ventnor-bugzilla) wrote : | #65 |
(In reply to comment #60)
> +void
> +nsPrintDialogW
> *aSettings)
> +{
> + aNS->SetOutputF
>
> Why do this? We should leave the output format alone.
No, the print dialog is just another consumer of the nsIPrintSettings code so it's in control of the object, and it needs to make sure that the output is sent in the format that it thinks is correct, which is GTK's autodetection.
> + aNS->SetPrintTo
>
> Don't do this either.
We have to since print-to-file is on by default, and since I put back the manual spool file copying for the embedders' sake, if I don't unset this it will never print.
> +
> aNS->SetPrinter
>
> And don't do this, the settings' internal GTK object is already correct!
>
> + // Now newPageSetup has a refcount of 2 (SetGtkPageSetup will addref), put
> it to 1 so if
> + // this gets replaced we don't leak.
> + g_object_
>
> Don't we need to unref gtkSettings as well?
No, its a direct pointer to the internal nsIPrintSettingsGTK private object.
>
> + return NS_ERROR_
> NS_ERROR_
>
> Please control yourself.
It'll be hard but I'll try. :)
> + mPrintSettings-
>
> Don't leak targetPath. Hmm, maybe here and elsewhere we should be using
> nsXPIDLString and getter_Copies? I think so.
>
> Why do you think toFileName is supposed to be a file: URI? Looks to me like
> it's meant to be a regular file path.
I used printf's to find out that its a file:// URI which is unsurprising since GTK uses those a lot. If I pass that to the old NS_NewNativeLoc
In Mozilla Bugzilla #193001, Jwalden+bmo (jwalden+bmo) wrote : | #66 |
> + else if (geckoPaper.
> + else if (gtkPaperName.
I'm pretty sure that this causes assertions in debug builds and flat-out doesn't work. If you're not running a debug build, you probably should be; if you are, I guess you just didn't hit these edge cases while doing manual testing (understandable given how much surface area there is to these changes).
You might want to have a QA person or two thoroughly exercise this to look for glitches in it, or perhaps ask for them to have people attack it at a test day or something after it lands (not sure how the whole "printing" part of that would work without asking people to print lots of garbage, tho).
In Mozilla Bugzilla #193001, Kherron+mozilla (kherron+mozilla) wrote : | #67 |
Michael, just a few comments if you don't mind:
1) You should update the initial developer and copyright date on the new files that you're adding.
2) You could remove the definition of |nsDeviceContex
3) After printing, what deletes the spool file? You also should delete the spool file if the print operation doesn't complete for some reason.
4) Is it necessary to special-case print-to-file in |nsDeviceContex
5) A temporary spool file--at least one intended for a printer--should be created with limited permissions, ie 0600. But IMO the user will expect print-to-file to result in a file with permissions reflecting his umask, eg 0644 if his umask is 0022. simply calling |MoveTo| on the spool file won't accomplish this.
In Mozilla Bugzilla #193001, Roc-ocallahan (roc-ocallahan) wrote : | #68 |
Thanks for the comments kherron!
> 4) Is it necessary to special-case print-to-file in
> |nsDeviceContex
> fine for me.
The issue is if an embedder calls SetPrintToFile/
In Mozilla Bugzilla #193001, Ventnor-bugzilla (ventnor-bugzilla) wrote : | #69 |
Created an attachment (id=297244)
Patch 6
Attempt to address all comments.
In Mozilla Bugzilla #193001, c7d2f5c8667d26fffd5e7772d632c76d (c7d2f5c8667d26fffd5e7772d632c76d-deactivatedaccount) wrote : | #70 |
+ // Is this print-to-file?
+ if (gtk_print_
+ aNS->SetPrintTo
+ return;
+ }
That's not the right way to detect print-to-file. Unfortunately, there is no way to detect whether print-to-file is requested in the print settings; the way gtk works is that in the to-file case the 'file' _printer_ is used. See http://
In Mozilla Bugzilla #193001, Ventnor-bugzilla (ventnor-bugzilla) wrote : | #71 |
(In reply to comment #66)
> + // Is this print-to-file?
> + if (gtk_print_
> + aNS->SetPrintTo
> + return;
> + }
>
> That's not the right way to detect print-to-file. Unfortunately, there is no
> way to detect whether print-to-file is requested in the print settings; the way
> gtk works is that in the to-file case the 'file' _printer_ is used. See
> http://
>
That code is gone in the latest patch.
In Mozilla Bugzilla #193001, Roc-ocallahan (roc-ocallahan) wrote : | #72 |
+ // Gets/Sets the printer name in the GtkPrintSettings. If no rpinter name is specified there,
Typo "rpinter"
+ nsresult _Clone(
+ nsresult _Assign(
Make them virtual to indicate that they override parent class methods. (Not strictly needed but it helps the reader.)
+ nsCAutoString url(gtk_
This should be an nsDependentCString.
+ if (!aToFileName || nsDependentStri
Might as well just check aToFileName[0] == 0.
surface = new gfxPDFSurface(
- } else {
+ else
surface = new gfxPSSurface(
Use surfaceSize.
Also "if (foo) blah; else corp;" isn't our style. Use braces please (or a ? : operator when reasonable).
+ nsresult PreloadPageSetup();
+
Take this out.
+ if (mToPrinter && !gtk_print_
Why this OUTPUT_URI check? We shouldn't need it.
The only remaining issue I'm concerned about is whether mIsInitedFromPr
In Mozilla Bugzilla #193001, Ventnor-bugzilla (ventnor-bugzilla) wrote : | #73 |
Created an attachment (id=297259)
Patch 6 nits fixed
To me that variable is also something that we don't need to worry about.
In Mozilla Bugzilla #193001, Roc-ocallahan (roc-ocallahan) wrote : | #74 |
Yeah, I think mIsInitedFromPr
In Mozilla Bugzilla #193001, Ventnor-bugzilla (ventnor-bugzilla) wrote : | #75 |
Created an attachment (id=297481)
Patch 6 more nits fixed
Put back modifications of those variables when needed.
In Mozilla Bugzilla #193001, Ventnor-bugzilla (ventnor-bugzilla) wrote : | #76 |
(From update of attachment 297481)
Requesting a1.9; We need to do all we can to improve the printing experience (printing web pages is a surprisingly common task!) and that includes killing off the asinine XUL print dialog on GTK.
In Mozilla Bugzilla #193001, Ventnor-bugzilla (ventnor-bugzilla) wrote : | #77 |
(In reply to comment #72)
> (From update of attachment 297481 [details])
> Requesting a1.9; We need to do all we can to improve the printing experience
> (printing web pages is a surprisingly common task!) and that includes killing
> off the asinine XUL print dialog on GTK.
>
At Roc's request I must seriously stress the horrific nature of our current setup. Things are so bad that changing advanced options requires typing in a custom _lpr command_ in a special text field. Unlike GNOME's dialog, almost nothing is presented pictorially so a lot of the time you have no idea of the effects of the values you are changing, and this switch gives us easy access to features that even Mozilla's system doesn't support yet GTK gives us for free due to the trivial rewrite of nsDeviceContext
CUPS will no longer have a monopoly on our GTK printing system which makes support of our GTK builds much easier to do on non-UNIX systems.
We bought a sexy new printer for the office so this has received a large amount of testing by me already, and I did design this patch to smoothly integrate things as much as possible.
In Mozilla Bugzilla #193001, Mtschrep (mtschrep) wrote : | #78 |
(From update of attachment 297481)
Michael this is awesome. You ready to catch any follow-
In Mozilla Bugzilla #193001, Ventnor-bugzilla (ventnor-bugzilla) wrote : | #79 |
(In reply to comment #74)
> (From update of attachment 297481 [details])
> Michael this is awesome. You ready to catch any follow-
>
I can only do my best! :-)
In Mozilla Bugzilla #193001, Reed Loden (reed) wrote : | #80 |
Checking in configure.in;
/cvsroot/
new revision: 1.1912; previous revision: 1.1911
done
Checking in config/
/cvsroot/
new revision: 3.33; previous revision: 3.32
done
Checking in embedding/
/cvsroot/
new revision: 1.19; previous revision: 1.18
done
RCS file: /cvsroot/
done
Checking in toolkit/
/cvsroot/
initial revision: 1.1
done
Checking in toolkit/
/cvsroot/
new revision: 1.45; previous revision: 1.44
done
Checking in layout/
/cvsroot/
new revision: 1.159; previous revision: 1.158
done
Checking in widget/
/cvsroot/
new revision: 1.116; previous revision: 1.115
done
RCS file: /cvsroot/
done
Checking in widget/
/cvsroot/
initial revision: 3.1
done
RCS file: /cvsroot/
done
Checking in widget/
/cvsroot/
initial revision: 3.1
done
Checking in widget/
/cvsroot/
new revision: 3.51; previous revision: 3.50
done
Checking in widget/
/cvsroot/
new revision: 1.71; previous revision: 1.70
done
Checking in widget/
/cvsroot/
new revision: 1.96; previous revision: 1.95
done
Checking in widget/
/cvsroot/
new revision: 1.42; previous revision: 1.41
done
RCS file: /cvsroot/
done
Checking in widget/
/cvsroot/
initial revision: 1.1
done
RCS file: /cvsroot/
done
Checking in widget/
/cvsroot/
initial revision: 1.1
done
Removing widget/
/cvsroot/
new revision: delete; previous revision: 1.1
done
Removing widget/
/cvsro...
In Mozilla Bugzilla #193001, Ginn-chen (ginn-chen) wrote : | #81 |
"nsDeviceContex
Should it be NS_ADDREF(
In Mozilla Bugzilla #193001, Reed Loden (reed) wrote : | #82 |
(In reply to comment #77)
> "nsDeviceContex
> accessible from nsDeviceContext
>
> Should it be NS_ADDREF(
Checking in widget/
/cvsroot/
new revision: 1.97; previous revision: 1.96
done
In Mozilla Bugzilla #193001, Ginn-chen (ginn-chen) wrote : | #83 |
It works.
In Mozilla Bugzilla #193001, Reed Loden (reed) wrote : | #84 |
This causes the printing test from bug 396024 to crash during mochitest.
Part of the stack:
(gdb) bt full
#0 0xffffe410 in __kernel_vsyscall ()
No symbol table info available.
#1 0xb73e8e96 in nanosleep () from /lib/tls/
No symbol table info available.
#2 0xb73e8ca7 in sleep () from /lib/tls/
No symbol table info available.
#3 0xb7f0ee03 in ah_crap_handler (signum=11) at nsSigHandlers.
No locals.
#4 0xb7f23251 in nsProfileLock:
oldact = (sigaction *) 0xb749bff4
#5 <signal handler called>
No symbol table info available.
#6 0xb5b95589 in DocumentViewerI
aPrintSetti
at /home/reed/
rv = <value optimized out>
xulDoc = {mRawPtr = 0x0}
docShell = {mRawPtr = 0x0}
presShell = {mRawPtr = 0x0}
#7 0xb7e0265d in NS_InvokeByIndex_P ()
at /home/reed/
m2 = 4562, m3 = "�X\000\
m3 = "�\000\
In Mozilla Bugzilla #193001, Reed Loden (reed) wrote : | #85 |
Glancing at the numbers, this actually might be a Ts win, too! :)
In Mozilla Bugzilla #193001, Martijn-martijn (martijn-martijn) wrote : | #86 |
The mochitest for bug 396024 is testing print preview code, but doesn't really work right now, because no printers are installed on the tinderboxes.
So it might be good to test if the patch doesn't cause a crash when no printers are installed.
Maybe bug 408355 is related?
Otherwise, I don't know why it's causing the crash. I guess you might want to disable the mochitest then, although I would prefer it if the crash was fixed.
In Mozilla Bugzilla #193001, Ventnor-bugzilla (ventnor-bugzilla) wrote : | #87 |
Created an attachment (id=297600)
Fix test failure
This special-cases print preview in GetSurfaceForPr
I think this is the problem, I can't really tell. But if no printers are on Tinderbox this seems likely.
In Mozilla Bugzilla #193001, Ventnor-bugzilla (ventnor-bugzilla) wrote : | #88 |
(From update of attachment 297600)
This doesn't fix it.
In Mozilla Bugzilla #193001, Ventnor-bugzilla (ventnor-bugzilla) wrote : | #89 |
Created an attachment (id=297920)
Fix test failure
It took a while but I finally figured out the test failure. Yay! It turns out it was an ugly race condition in the event loop which caused one of the frames to be destroyed before we got the chance to show the print preview. This is fixed by moving the printer enumeration (which causes the probing of the event loop) to a much later location.
Some code had to be changed to make sure this move didn't cause more crashes. I also added a failure return where the crash happened. We return early when we detect the absence of other important global variables, so why not the mContainer? This will make print and print preview much safer.
In Mozilla Bugzilla #193001, Roc-ocallahan (roc-ocallahan) wrote : | #90 |
This is definitely an improvement, but we're potentially just moving the crash to code that creates the devicecontextspec, namely nsPrintEngine:
Or else we could do something a little more outrageous and maintain the default printer in nsToolkitGTK, by re-getting the default printer periodically and asynchronously.
In Mozilla Bugzilla #193001, Kherron+mozilla (kherron+mozilla) wrote : | #91 |
(In reply to comment #86)
> Or else we could do something a little more outrageous and maintain the default
> printer in nsToolkitGTK, by re-getting the default printer periodically and
> asynchronously.
As I understand it, neither the GTK nor CUPS layer caches printers, so each printer enumeration can result in queries to remote print servers. See eg <http://
In Mozilla Bugzilla #193001, Ventnor-bugzilla (ventnor-bugzilla) wrote : | #92 |
(In reply to comment #86)
> This is definitely an improvement, but we're potentially just moving the crash
> to code that creates the devicecontextspec, namely
> nsPrintEngine:
> figure out which one we should make potentially spin the event loop.
The problem is there is no "silent printing API's", it all takes the same path. Its just that silent printing skips the code that shows the print dialog. The reason I put it there is to do it as least as possible. We don't need it for print preview and the print dialog will give us a GtkPrinter anyway. I think this is the safest place to put it, and with the extra failure checks in nsDocumentViewer it will become even safer.
> Or else we could do something a little more outrageous and maintain the default
> printer in nsToolkitGTK, by re-getting the default printer periodically and
> asynchronously.
We should never do anything that can encourage races, in this case between nsToolkitGTK and nsDeviceContext
In Mozilla Bugzilla #193001, Roc-ocallahan (roc-ocallahan) wrote : | #93 |
(In reply to comment #88)
> I think
> this is the safest place to put it, and with the extra failure checks in
> nsDocumentViewer it will become even safer.
Those checks may block that particular crash, but processing events during nsDeviceContext
> > Or else we could do something a little more outrageous and maintain the
> > default printer in nsToolkitGTK, by re-getting the default printer
> > periodically and asynchronously.
>
> We should never do anything that can encourage races, in this case between
> nsToolkitGTK and nsDeviceContext
What races? You're worried about the default printer changing or going away between the poll and the print?
How do things work today? If CUPS already does some kind of expensive checking of remote printers, do we just block completely? do we process events during that time? if we process events, during which print API call? Someone please read the code so I don't have to.
In Mozilla Bugzilla #193001, Roc-ocallahan (roc-ocallahan) wrote : | #94 |
This seems lame, GTK must have some local knowledge of what the default printer is, but there doesn't seem any way to get that directly.
As a mega-lame solution to "silent printing", could we open the print dialog and then instantly close it as if the user had clicked OK?
In Mozilla Bugzilla #193001, Roc-ocallahan (roc-ocallahan) wrote : | #95 |
We decided to add a new SetupSilentPrinting method to nsIPrintSettings that will be called by nsPrintEngine:
In Mozilla Bugzilla #193001, Ventnor-bugzilla (ventnor-bugzilla) wrote : | #96 |
Created an attachment (id=298171)
Attempt to constrain the event loop run
Yeah, this seems to work.
In Mozilla Bugzilla #193001, Roc-ocallahan (roc-ocallahan) wrote : | #97 |
(From update of attachment 298171)
+ /**
+ * We call this function so that anything that requires a run of the event loop
+ * can do so safely. The print dialog runs the event loop but in silent printing
+ * that doesn't happen.
+ */
Please document that either SetupSilentPrinting or ShowPrintDialog (but not both) must be called by the print engine when actually printing.
+ // XXX Some platforms allow the user to change the ShrinkToFit option so change it here too
How about
"// The user might have changed shrink-to-fit in the print dialog, so update our copy of its state"
(shouldn't be XXX since there is not a known probem with this)
In Mozilla Bugzilla #193001, Ventnor-bugzilla (ventnor-bugzilla) wrote : | #98 |
Created an attachment (id=298173)
Comment fix
In Mozilla Bugzilla #193001, Ventnor-bugzilla (ventnor-bugzilla) wrote : | #99 |
Created an attachment (id=298177)
...And rev the UUID
I'm so bad at remembering to do this :(
In Mozilla Bugzilla #193001, Ventnor-bugzilla (ventnor-bugzilla) wrote : | #100 |
Created an attachment (id=298186)
...And update to tip
In Mozilla Bugzilla #193001, Roc-ocallahan (roc-ocallahan) wrote : | #101 |
I just realized that nsIPrintSettingsGTK shouldn't be IDL. In fact, it shouldn't even exist. The code should just use nsPrintSettingsGTK directly.
In Mozilla Bugzilla #193001, Ventnor-bugzilla (ventnor-bugzilla) wrote : | #102 |
Created an attachment (id=298194)
Address Roc's literally last-second interface rewrite comment
When this gets checked in, the files nsPrintJobFacto
In Mozilla Bugzilla #193001, Roc-ocallahan (roc-ocallahan) wrote : | #103 |
(From update of attachment 298194)
+#define NS_IPRINTSETTIN
call it NS_PRINTSETTING
In Mozilla Bugzilla #193001, Ventnor-bugzilla (ventnor-bugzilla) wrote : | #104 |
Created an attachment (id=298195)
Address picky comment
In Mozilla Bugzilla #193001, Reed Loden (reed) wrote : | #105 |
Created an attachment (id=298199)
Include file removals and remove some other old code
In Mozilla Bugzilla #193001, Reed Loden (reed) wrote : | #106 |
Checking in configure.in;
/cvsroot/
new revision: 1.1916; previous revision: 1.1915
done
Checking in config/
/cvsroot/
new revision: 3.35; previous revision: 3.34
done
Checking in embedding/
/cvsroot/
new revision: 1.21; previous revision: 1.20
done
Checking in toolkit/
/cvsroot/
new revision: 1.3; previous revision: 1.2
done
Checking in toolkit/
/cvsroot/
new revision: 1.47; previous revision: 1.46
done
Checking in layout/
/cvsroot/
new revision: 1.161; previous revision: 1.160
done
Checking in layout/
/cvsroot/
new revision: 1.561; previous revision: 1.560
done
Checking in widget/
/cvsroot/
new revision: 1.42; previous revision: 1.41
done
Checking in widget/
/cvsroot/
new revision: 1.119; previous revision: 1.118
done
Checking in widget/
/cvsroot/
new revision: 3.3; previous revision: 3.2
done
Checking in widget/
/cvsroot/
new revision: 1.44; previous revision: 1.43
done
Checking in widget/
/cvsroot/
new revision: 3.53; previous revision: 3.52
done
Checking in widget/
/cvsroot/
new revision: 1.73; previous revision: 1.72
done
Checking in widget/
/cvsroot/
new revision: 1.99; previous revision: 1.98
done
Checking in widget/
/cvsroot/
new revision: 1.44; previous revision: 1.43
done
Removing widget/
/cvsroot/
new revision: delete; previous revision: 1.2
done
Checking in widget/
/cvsroot/
new revision: 1.3; previous revision: 1.2
done
Checking in widget/
/cvsroot/
new revision: 1.3; previous revision: ...
Changed in firefox: | |
status: | Confirmed → Fix Released |
In Mozilla Bugzilla #193001, Ventnor-bugzilla (ventnor-bugzilla) wrote : | #107 |
Created an attachment (id=298352)
Possible Crash follow-up
This may be the cause of some people's crashes lately, see if this fixes anything.
In Mozilla Bugzilla #193001, Reed Loden (reed) wrote : | #108 |
Checking in widget/
/cvsroot/
new revision: 1.4; previous revision: 1.3
done
In Mozilla Bugzilla #193001, Fredrik Larsson (nossralf) wrote : | #109 |
For reference, the "crashes on File > Page Setup" bug is bug 413414. (I hope this doesn't qualify as bug spam.)
In Mozilla Bugzilla #193001, Ventnor-bugzilla (ventnor-bugzilla) wrote : | #110 |
Created an attachment (id=298404)
Followup 2: HIG fixes
This will make the custom text dialog obey the HIG more by switching the order of the buttons, and marking one as the default for when you press Enter.
In Mozilla Bugzilla #193001, Reed Loden (reed) wrote : | #111 |
Checking in widget/
/cvsroot/
new revision: 1.4; previous revision: 1.3
done
In Mozilla Bugzilla #193001, Ispence (ispence) wrote : | #112 |
This is just a nitpick, but it'd be nice if the page setup and other dialogs had a firefox icon (well, the icon of the program using the toolkit)
Sebastian Urban (surban) wrote : | #113 |
Firefox 3 is included in Hardy.
Changed in firefox: | |
status: | Incomplete → Fix Released |
Changed in firefox: | |
importance: | Unknown → Wishlist |
bryner says he'll take this, fwiw.
/be