Closed Bug 188508 Opened 22 years ago Closed 22 years ago

Upgrade print dialog PDE

Categories

(Core :: Printing: Output, defect)

PowerPC
macOS
defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla1.4beta

People

(Reporter: ccarlen, Assigned: ccarlen)

References

Details

(Keywords: platform-parity)

Attachments

(2 files)

This is the Product=Browser, trunk version of bug 186401. Unless anybody objects, I'd like to avoid posting a new patch. Attachment 110248 [details] [diff] is from the trunk anyway. I've made these improvements to it since it was originally checked into Chimera: (1) Incorporated Simon's dialog pane beautification. (2) The name of the pane in the menu is now the application name, not always "WebBrowser." Can I have r/sr to get this into the trunk.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.3beta
r/sr=sfraser Do we want to add page margin, header/footer UI?
Seawood - one thing I'd like your opinion on from the patch: +libs:: + pbxbuild -buildstyle $(BUILDSTYLE) install + cp -R build/UninstalledProducts/PrintPDE.plugin $(DIST) The finished PDE gets dumped into $(DIST). Later, it's copied from there into the application bundle. I didn't want that Makefile to go digging into component dirs to get parts for the bundle. Same goes for embedding apps. Should we have a new dir in $(DIST) where components put things which are meant to be put into the final bundle?
mmh'm, print goodness for the trunk. ;)
Keywords: nsbeta1, pp
Target Milestone: mozilla1.3beta → mozilla1.4alpha
QA Contact: sujay → sairuh
Sorry, Conrad. I missed this bug the first time around. I'm not sure how making another $(DIST) subdir is going to improve things. The embeddors will still need to know what to copy from that extra dir and where to copy it. OTOH, creating a duplicate application bundle dir heirarchy inside $(DIST) seems like overkill but may work.
> I'm not sure how making another $(DIST) subdir is going to improve things. It provides a constant place from which the embedding app (or mozilla) can pick up these items - rather then digging into the component dirs where these things are built. For instance, the old print dialog PDE was in gfx, now it's not. Like other things, we should export this, but since it's not a lib, or an include...
*** Bug 198313 has been marked as a duplicate of this bug. ***
*** Bug 177976 has been marked as a duplicate of this bug. ***
Will this also return the Print Selection Only capability referred to by bug 197799?
-> 1.4b
Target Milestone: mozilla1.4alpha → mozilla1.4beta
In addition to this patch, the whole directory gfx/src/mac/printerplugin will be removed.
Comment on attachment 119199 [details] [diff] [review] updated patch, with addition of building in objdir build Asking for Pink's r=, carrying over Simon's (if that works)
Attachment #119199 - Flags: superreview+
Attachment #119199 - Flags: review?(pinkerton)
Looks good to me.
Comment on attachment 119199 [details] [diff] [review] updated patch, with addition of building in objdir build r=pink
Attachment #119199 - Flags: review?(pinkerton) → review+
Fixed. I'll need to tweak the Camino project so the PDE is in Camino's bundle again - remembered that a moment too late :-/
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
JJ, I just downloaded a nightly (20030403) and the print dialog plugin is not in its bundle. Since I checked this in yesterday, I can see the plugin gets built on the Tinderbox logs, and it gets copied to the bundle here: mkdir -p ../../dist/MozillaDebug.app/Contents/Plug-Ins cp -R ../../dist/PrintPDE.plugin ../../dist/MozillaDebug.app/Contents/Plug-Ins How could it then not end up in the nightly? Is the packaging automation doing some filtering of the bundle contents?
todays' build was delayed and got only posted on mozilla.org at 10am PDT. You must have looked at an older build. I just checked it and I do see PrintPDE.plugin inside Mozilla.app/Contents/Plug-Ins
i don't see the "Web Browser" option in the native print dlg in today's (2003.04.09.10) comm trunk (nscp) build. is there still some tweaking/another bug that needs to get resolved before it's exposed? (i noticed that it's not in the camino trunk build yet, per comment 15. any eta when that'll be fixed? just curious. :)
thanks, conrad!
> i don't see the "Web Browser" option You won't - that wasn't right anyway. Now, the name of the PDE pane in the print dialog is dynamically set to the the name of the application (same as in the dock).
vrfy'd fixed with 2003.04.14.10 comm trunk bits on Mac OS X 10.2.5. thanks a lot, conrad! i've spun off another bug for comment 1: bug 202014.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: