Can you explain this bug a little better?
The solution for this bug will be to introduce a "pluggable" dialog service.
Just like the network libs use the nsIPrompt mechanism for flynig dialogs and
embedders can override them with their own dialogs.
My guess is that much like what we do for netwerk, we will pass in a
nsIInterfaceRequestor for callbacks and then do a GetInterface on the callbacks
for the nsIPrintingPrompt interface.
The implementation of that can then be elsewhere like in the embedding
directory. The a particular platform can choose to use the nsIInterfaceRequestor
or just fly their own native one.
On Windows we may move entirely away from the XPDialog, but certainly for Linux
we need to do this.
I assume this solution would remove entirely the dependencies in gfx on dom and
windowwatcher? Would gfx become dependent on embedcomponents, or would print
dialogs be invoked entirely from outside of gfx?
nsbeta1- per adt triage
topembed+ per adt triage
How does this affect bug 136058 ("Implement nsPrinterFeatures" - the idea of
this RFE is to create a service to query printer properties/attributes like
available paper sizes/orientations for a specified printer...) ?
AFAIK embedders would need this info to "fly their" print dialog without using
hardcoded values in their print dialog (currently both PostScript module and
Xprint module use the printerfeatures prototype in
nsDeviceContextSpecGTK/nsDeviceContextSpecXlib - we only need to make the code a
XPCOM service... :)
Created attachment 81155 [details] [diff] [review]
Phase #2 patch
Phase #1 patch is in Bug 135441 I will attach an overview document soon.
Created attachment 82090 [details] [diff] [review]
this is more up-to-date
Since you are already touching all platforms - is it possible to implement the
API calls for bug 133258 ("Enhance nsIDeviceContext print API with an additional
level to support multiple documents in one print job") with this patch - or (at
least) rename s/BeginDocument/BeginJob/ and s/EndDocument/EndJob/, please ?
Created attachment 82120 [details]
Read about Phase #2
Glad to see that nsIPrintPromptService has landed, but, needless to say, a
pluggable print dialog system is useless if mozilla doesn't invoke print dialogs
through it. I hope rod's patch can land asap; we're (galeon) still getting
Heh, spoke too soon eh? Roadmap looks good.
Comment on attachment 82090 [details] [diff] [review]
Comment on attachment 82090 [details] [diff] [review]
sr=attinasi, based partially on email comments that testing has been thorough
and on all platforms
verifying, this has been working for a couple of weeks
Let's get this verified by QA either on the trunk or if they are substantial,
please create a test build with the batch and the branch and let QA test that.
this patch has a bunch of conflicts.
Created attachment 83866 [details] [diff] [review]
this is what was checked in
Here the patch of what was checked in and this is a list of things that had
1) Change to encode '\n' as '_' in printer names for prefs (apparently I was
testing this idea; took out the calling code but left this in, the code worked
fin ein testing)
2) The nsDeviceContextSpecOS2.cpp which had conflicts was changed to the one
mkapply sent me.
3) At the last minute we discovered that the attr isPrintPreview in the
nsIWebBrowserPrint was no longer being used, so I removed the two calls to it
in DocViewer, It was removed later from the IDL.
4) Several Mac makefile file changes that came out of the last round of builds
5) For reason I can't explain I must changed to debug output statments from
inside a "if (doDebug)" if statment in printjoboptions.js
6) A bunch of stuff removed from
embedding/browser/powerplant/source/CPrintAttachment.cpp and few lines added to
better use the new APIs (I reviewed)
7) A change in an embedding make to use a renamed directory from gtk to
8) A bunch of changes to get the viewer app working with printing again.
So here is my justification for checking this all in without further reviews:
Conrad had just spent a lot of time diligently doing builds on Mac for Mac9,
Carbon, and OSX. Waiting any length of time might for re-reviews for I think
are fairly minor issues might require doing builds on the Mac again.
Item #1 - that is the only item of concern, but it works fine.
Item #3 - I didn't feel removing code was worth a re-review.
Item #6 - I reviewed.
Item #8 - nobody but the layout-group cares about viewer and I am usually the
only one you uses the Print" menu item, so I figure that didn't really need to
be reviewed at this point, I didn't even have a bug on this, so obivously
nobody uses it.
Most of the others were makefile changes that cam out of Conrad's builds.
Created attachment 84098 [details] [diff] [review]
patch against the branch
This is the the patch against the branch, al the new embedding files are
already in on the branch, but not in the build.
Created attachment 84100 [details] [diff] [review]
Merged against the Branch
Attachment 84098 [details] [diff] is in Bug 135441
This attachment is the correct one
adding adt1.0.0+. Please get drivers approval and then check into the 1.0 branch.
changing to adt1.0.1+ for checkin to the 1.0 branch. Please get drivers
approval before checking in.
please land on the 1.0.1 branch. once there, remove the "mozilla1.0.1+" keyword,
and add the "fixed1.0.1" keyword.
checked in on branch