Re: [Development] QtPrintSupport - Platform Support
On Friday 04 May 2012 09:26:26 Sean Harmer wrote: > On 04/05/2012 08:11, Christoph Schleifenbaum wrote: > > 3 maj 2012 kl. 21:41 skrev John Layt: > >> Many thanks Christoph for sorting it so quickly. The crash fix works > >> perfectly, and using Patch Set 4 does fix the NativeFormat problem but > >> not the PdfFormat. With PdfFormat the layout is now correct, but the > >> actual glyph size is tiny. I'll post a copy of the PDF to the bug > >> report. > > > > Thanks for testing. I re-tested it and get that result if I apply patch > > set 3. With patch set 4 it works. Are you sure you applied the fourth > > one? Someone else has the same result? > I can also confirm that patchset 4 works as expected. > > Cheers, > > Sean Weird, I eye-balled the diff and it was patch set 4, so I nuked the branch and did a clean checkout and rebuild and now it works perfectly :-) I blame git... Anyway, thanks again for the quick fixes, that's 2 of the print blockers gone :-) Cheers! John. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtPrintSupport - Platform Support
On 04/05/2012 08:11, Christoph Schleifenbaum wrote: > 3 maj 2012 kl. 21:41 skrev John Layt: >> On Thursday 03 May 2012 20:50:44 Christoph Schleifenbaum wrote: >>> 3 maj 2012 kl. 12:30 skrev Christoph Schleifenbaum: 3 maj 2012 kl. 11:47 skrev Sean Harmer: > On Tuesday 01 May 2012 23:21:50 John Layt wrote: > > >> I've been testing the Mac printing and unfortunately hit a couple of >> release blockers that it would be great if a Mac person could have a >> look at sometime and give an opinion: >> >> https://bugreports.qt-project.org/browse/QTBUG-2 > Christoph has fixed this one: > > https://codereview.qt-project.org/#change,25065 This one covers only the PrintPfdViaMac.pdf case. Not the other one yet. >>> Now it covers both cases. Feel free to review. >>> >>> >>> The crash from QTBUG-25553 is fixed as well now. >>> >>> >>> Christoph >> Many thanks Christoph for sorting it so quickly. The crash fix works >> perfectly, and using Patch Set 4 does fix the NativeFormat problem but not >> the >> PdfFormat. With PdfFormat the layout is now correct, but the actual glyph >> size is tiny. I'll post a copy of the PDF to the bug report. > > Thanks for testing. I re-tested it and get that result if I apply patch set > 3. With patch set 4 it works. Are you sure you applied the fourth one? > Someone else has the same result? I can also confirm that patchset 4 works as expected. Cheers, Sean -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtPrintSupport - Platform Support
On 4.5.2012 10.11, "Christoph Schleifenbaum" wrote: >3 maj 2012 kl. 21:41 skrev John Layt: >> On Thursday 03 May 2012 20:50:44 Christoph Schleifenbaum wrote: >>> 3 maj 2012 kl. 12:30 skrev Christoph Schleifenbaum: 3 maj 2012 kl. 11:47 skrev Sean Harmer: > On Tuesday 01 May 2012 23:21:50 John Layt wrote: > > >> I've been testing the Mac printing and unfortunately hit a couple of >> release blockers that it would be great if a Mac person could have a >> look at sometime and give an opinion: >> >> https://bugreports.qt-project.org/browse/QTBUG-2 > > Christoph has fixed this one: > > https://codereview.qt-project.org/#change,25065 This one covers only the PrintPfdViaMac.pdf case. Not the other one yet. >>> >>> Now it covers both cases. Feel free to review. >>> >>> >>> The crash from QTBUG-25553 is fixed as well now. >>> >>> >>> Christoph >> >> Many thanks Christoph for sorting it so quickly. The crash fix works >> perfectly, and using Patch Set 4 does fix the NativeFormat problem but >>not the >> PdfFormat. With PdfFormat the layout is now correct, but the actual >>glyph >> size is tiny. I'll post a copy of the PDF to the bug report. > > >Thanks for testing. I re-tested it and get that result if I apply patch >set 3. With patch set 4 it works. Are you sure you applied the fourth >one? Someone else has the same result? Glyph size looks correct to me also after applying the patch set 4. BR, - Teemu > > >Cheers, >Christoph > >-- >Christoph Schleifenbaum | christoph.schleifenb...@kdab.com | Software >Engineer >Klarälvdalens Datakonsult AB, a KDAB Group company >Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) >KDAB - Qt Experts - Platform-independent software solutions > >___ >Development mailing list >Development@qt-project.org >http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtPrintSupport - Platform Support
3 maj 2012 kl. 21:41 skrev John Layt: > On Thursday 03 May 2012 20:50:44 Christoph Schleifenbaum wrote: >> 3 maj 2012 kl. 12:30 skrev Christoph Schleifenbaum: >>> 3 maj 2012 kl. 11:47 skrev Sean Harmer: On Tuesday 01 May 2012 23:21:50 John Layt wrote: > I've been testing the Mac printing and unfortunately hit a couple of > release blockers that it would be great if a Mac person could have a > look at sometime and give an opinion: > > https://bugreports.qt-project.org/browse/QTBUG-2 Christoph has fixed this one: https://codereview.qt-project.org/#change,25065 >>> >>> This one covers only the PrintPfdViaMac.pdf case. Not the other one yet. >> >> Now it covers both cases. Feel free to review. >> >> >> The crash from QTBUG-25553 is fixed as well now. >> >> >> Christoph > > Many thanks Christoph for sorting it so quickly. The crash fix works > perfectly, and using Patch Set 4 does fix the NativeFormat problem but not > the > PdfFormat. With PdfFormat the layout is now correct, but the actual glyph > size is tiny. I'll post a copy of the PDF to the bug report. Thanks for testing. I re-tested it and get that result if I apply patch set 3. With patch set 4 it works. Are you sure you applied the fourth one? Someone else has the same result? Cheers, Christoph -- Christoph Schleifenbaum | christoph.schleifenb...@kdab.com | Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtPrintSupport - Platform Support
On Thursday 03 May 2012 20:50:44 Christoph Schleifenbaum wrote: > 3 maj 2012 kl. 12:30 skrev Christoph Schleifenbaum: > > 3 maj 2012 kl. 11:47 skrev Sean Harmer: > >> On Tuesday 01 May 2012 23:21:50 John Layt wrote: > >> > >> > >>> I've been testing the Mac printing and unfortunately hit a couple of > >>> release blockers that it would be great if a Mac person could have a > >>> look at sometime and give an opinion: > >>> > >>> https://bugreports.qt-project.org/browse/QTBUG-2 > >> > >> Christoph has fixed this one: > >> > >> https://codereview.qt-project.org/#change,25065 > > > > This one covers only the PrintPfdViaMac.pdf case. Not the other one yet. > > Now it covers both cases. Feel free to review. > > > The crash from QTBUG-25553 is fixed as well now. > > > Christoph Many thanks Christoph for sorting it so quickly. The crash fix works perfectly, and using Patch Set 4 does fix the NativeFormat problem but not the PdfFormat. With PdfFormat the layout is now correct, but the actual glyph size is tiny. I'll post a copy of the PDF to the bug report. Cheers! John. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtPrintSupport - Platform Support
3 maj 2012 kl. 12:30 skrev Christoph Schleifenbaum: > > 3 maj 2012 kl. 11:47 skrev Sean Harmer: > >> On Tuesday 01 May 2012 23:21:50 John Layt wrote: >> >>> I've been testing the Mac printing and unfortunately hit a couple of release >>> blockers that it would be great if a Mac person could have a look at >>> sometime and give an opinion: >>> >>> https://bugreports.qt-project.org/browse/QTBUG-2 >> >> Christoph has fixed this one: >> >> https://codereview.qt-project.org/#change,25065 > > This one covers only the PrintPfdViaMac.pdf case. Not the other one yet. Now it covers both cases. Feel free to review. The crash from QTBUG-25553 is fixed as well now. Christoph -- Christoph Schleifenbaum | christoph.schleifenb...@kdab.com | Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtPrintSupport - Platform Support
3 maj 2012 kl. 11:47 skrev Sean Harmer: > On Tuesday 01 May 2012 23:21:50 John Layt wrote: > >> I've been testing the Mac printing and unfortunately hit a couple of release >> blockers that it would be great if a Mac person could have a look at >> sometime and give an opinion: >> >> https://bugreports.qt-project.org/browse/QTBUG-2 > > Christoph has fixed this one: > > https://codereview.qt-project.org/#change,25065 This one covers only the PrintPfdViaMac.pdf case. Not the other one yet. Christoph -- Christoph Schleifenbaum | christoph.schleifenb...@kdab.com | Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtPrintSupport - Platform Support
On Tuesday 01 May 2012 23:21:50 John Layt wrote: > I've been testing the Mac printing and unfortunately hit a couple of release > blockers that it would be great if a Mac person could have a look at > sometime and give an opinion: > > https://bugreports.qt-project.org/browse/QTBUG-2 Christoph has fixed this one: https://codereview.qt-project.org/#change,25065 > https://bugreports.qt-project.org/browse/QTBUG-25553 Christoph is now looking at this one too. :) Sean -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtPrintSupport - Platform Support
On Monday 30 Apr 2012 09:06:28 morten.sor...@nokia.com wrote: > That would be "not possible". QtGui and Widgets loads the Cocoa backend as a > plugin and does not link agains it. > > I think the only options are either duplicating the neccesary code to > support QCoreGraphicsPaintEngine in printsupport, or let it live in the > cocoa plugin and "export" it using QCocoaNativeInterface. I don't like > duplicating code so we went with the latter approach. > > Morten Thanks Morten, I understand it now, you never understand a thing properly until you try break it apart :-) I'll document that somewhere and set a task for "some future release" to see if we can at least untangle QMacPrintEngine and QCocoaPrinterSupport from QCoreGraphicsPaintEngine and move them into the printer plugin. I've been testing the Mac printing and unfortunately hit a couple of release blockers that it would be great if a Mac person could have a look at sometime and give an opinion: https://bugreports.qt-project.org/browse/QTBUG-2 https://bugreports.qt-project.org/browse/QTBUG-25553 Cheers! John. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtPrintSupport - Platform Support
On segunda-feira, 30 de abril de 2012 09.06.28, morten.sor...@nokia.com wrote: > Unfortunately, QCoreGraphicsPaintEngine needs to link against the Cocoa > platform plugin to use classes/methods in QCocoaAutoReleasePool and > QCocoaHelpers, but I can't figure out how to do that in qmake. QtGui and > QtWidget both use these classes/methods as well, but I can't figure out how > they are linking against the Cocoa plugin. Any hints on linking qtcocoa > into cocoaprintersupport, or is that just not possible? You can't link against a plugin. Looks like those classes should be in platformsupport instead. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtPrintSupport - Platform Support
On Apr 28, 2012, at 5:38 PM, ext John Layt wrote: Well I've tried doing this and ended up moving QCocoaPrinterSupport, QQMacPrintEngine and QCoreGraphicPaintEngine all into the the printsupport plugin as they are all only used by QtPrintSupport, and as the plugin returns the native QPrintEngine as its main purpose so it seems logical. Unfortunately, QCoreGraphicsPaintEngine needs to link against the Cocoa platform plugin to use classes/methods in QCocoaAutoReleasePool and QCocoaHelpers, but I can't figure out how to do that in qmake. QtGui and QtWidget both use these classes/methods as well, but I can't figure out how they are linking against the Cocoa plugin. Any hints on linking qtcocoa into cocoaprintersupport, or is that just not possible? That would be "not possible". QtGui and Widgets loads the Cocoa backend as a plugin and does not link agains it. I think the only options are either duplicating the neccesary code to support QCoreGraphicsPaintEngine in printsupport, or let it live in the cocoa plugin and "export" it using QCocoaNativeInterface. I don't like duplicating code so we went with the latter approach. Morten ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtPrintSupport - Platform Support
On Monday 23 Apr 2012 22:17:15 John Layt wrote: > For Mac I propose moving QCocoaPrinterSupport into > plugins/printsupport/cocoa and moving the private methods from > QCocoaNativeInterface to > QCocoaPrinterSupportPlugin. I'll do a patch. > > A harder question is where QMacPrintEngine should be, should it go to > plugins/printsupport/cocoa, or to printsupport/kernel like the current > Windows and Cups implementations? The QMacPrintDialog could have the same > question, does it belong in plugins/printsupport/cocoa, or to > printsupport/dialogs? I'm inclined to have all the platform specific code > in the plugin if possible, and change Windows and Cups to match. Hi, Well I've tried doing this and ended up moving QCocoaPrinterSupport, QQMacPrintEngine and QCoreGraphicPaintEngine all into the the printsupport plugin as they are all only used by QtPrintSupport, and as the plugin returns the native QPrintEngine as its main purpose so it seems logical. Unfortunately, QCoreGraphicsPaintEngine needs to link against the Cocoa platform plugin to use classes/methods in QCocoaAutoReleasePool and QCocoaHelpers, but I can't figure out how to do that in qmake. QtGui and QtWidget both use these classes/methods as well, but I can't figure out how they are linking against the Cocoa plugin. Any hints on linking qtcocoa into cocoaprintersupport, or is that just not possible? Cheers! John. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtPrintSupport - Platform Support
On Monday 23 Apr 2012 13:20:08 morten.sor...@nokia.com wrote: > On Apr 22, 2012, at 10:43 PM, ext John Layt wrote: > > OSX: > > > > src/plugins/platforms/cocoa- QMacPrintEngine > >- QCoreGraphicsPaintEngine > >- QCocoaPrinterSupport > > > > src/plugins/printsupport/cocoa - QCocoaPrinterSupportPlugin > > Windows: > > > > src/plugins/platforms/windows - none > > src/plugins/printsupport/cocoa - QWindowsPrinterSupportPlugin > >- QWindowsPrinterSupport > > > > src/printsupport/kernel- QWin32PrintEngine > > Can anyone explain why we have these differences, or any objections why we > > shouldn't move them around to be consistent: > QMacPrintEngine and QCoreGraphicsPaintEngine are class names from Qt 4. For > Qt 5 we adopted the "QCocoa" prefix - hence the mismatch. I would like to > keep "QCoreGraphicsPaintEngine", which describes exactly what it is (I > guess the same can be said for "QPdfPrintEngine"). QMacPrintEngine can be > renamed to QCocoaPrintEngine. Thanks, but perhaps I wasn't quite clear enough, I'm wondering why the Mac and Windows printersupport plugins are structured differently and why the files/classes themselves are in different locations and plugins. For Mac I was more interested in why the classes are in plugins/platforms/cocoa instead of plugins/printsupport/cocoa or printsupport/kernel like for Windows. Ideally, the platform plugins should know nothing about QtPrintSupport which we plan to deprecate later. All the QtPrintSupport specific classes should be in the separate printsupport plugin and so more easily switched when the new print module eventually appears. I've looked at it a bit more and it seems to be related to QCocoaNativeInterface which has a couple of private Q_INVOKABLE methods related to creating the QCocoaPrinterSupport object, but I'm not sure why these need to be there when they could be in the QCocoaPrinterSupportPlugin? For Mac I propose moving QCocoaPrinterSupport into plugins/printsupport/cocoa and moving the private methods from QCocoaNativeInterface to QCocoaPrinterSupportPlugin. I'll do a patch. A harder question is where QMacPrintEngine should be, should it go to plugins/printsupport/cocoa, or to printsupport/kernel like the current Windows and Cups implementations? The QMacPrintDialog could have the same question, does it belong in plugins/printsupport/cocoa, or to printsupport/dialogs? I'm inclined to have all the platform specific code in the plugin if possible, and change Windows and Cups to match. Cheers! John. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtPrintSupport - Platform Support
On Apr 22, 2012, at 10:43 PM, ext John Layt wrote: > Hi, > > While starting to review the current state of QtPrintSupport for Beta 1 and > one thing I've immediately noticed is an inconsistency in the platform > implementations as to which plugins have which classes where. > > OSX: > > src/plugins/platforms/cocoa- QMacPrintEngine > - QCoreGraphicsPaintEngine > - QCocoaPrinterSupport > src/plugins/printsupport/cocoa - QCocoaPrinterSupportPlugin > > Windows: > > src/plugins/platforms/windows - none > src/plugins/printsupport/cocoa - QWindowsPrinterSupportPlugin > - QWindowsPrinterSupport > src/printsupport/kernel- QWin32PrintEngine > - QAlphaPaintEngine > > > Linux: > > src/platformsupport/genericunix - QGenericUnixPrinterSupport > src/printsupport/kernel - QPdfPrintEngine >- QCUPSSupport >- qprinterinfo_unix > > Can anyone explain why we have these differences, or any objections why we > shouldn't move them around to be consistent: > QMacPrintEngine and QCoreGraphicsPaintEngine are class names from Qt 4. For Qt 5 we adopted the "QCocoa" prefix - hence the mismatch. I would like to keep "QCoreGraphicsPaintEngine", which describes exactly what it is (I guess the same can be said for "QPdfPrintEngine"). QMacPrintEngine can be renamed to QCocoaPrintEngine. - Morten ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] QtPrintSupport - Platform Support
Hi, While starting to review the current state of QtPrintSupport for Beta 1 and one thing I've immediately noticed is an inconsistency in the platform implementations as to which plugins have which classes where. OSX: src/plugins/platforms/cocoa- QMacPrintEngine - QCoreGraphicsPaintEngine - QCocoaPrinterSupport src/plugins/printsupport/cocoa - QCocoaPrinterSupportPlugin Windows: src/plugins/platforms/windows - none src/plugins/printsupport/cocoa - QWindowsPrinterSupportPlugin - QWindowsPrinterSupport src/printsupport/kernel- QWin32PrintEngine - QAlphaPaintEngine Linux: src/platformsupport/genericunix - QGenericUnixPrinterSupport src/printsupport/kernel - QPdfPrintEngine - QCUPSSupport - qprinterinfo_unix Can anyone explain why we have these differences, or any objections why we shouldn't move them around to be consistent: src/plugins/platforms/xxx- QxxxPaintEngine src/plugins/printsupport/xxx - QxxxPrinterSupportPlugin - QxxxPrinterSupport - QxxxPrintEngine We could then move all the CUPS specific stuff into src/plugins/printsupport/cups I'm also concerned about QT_NO_CUPS and QT_NO_LPR. I'd like to make it more explicit that we only support Linux printing using CUPS and remove all references to LPR and QT_NO_LPR altogether (including all the AIX/HPUX/Solaris/IRIX code still left!). QT_NO_CUPS would then also be redundant as we have QT_NO_PRINTER already. Thoughts? John. P.S. Please also note that the auto tests are seriously broken and shouldn't be relied upon when making changes. I'm working on sorting this out. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
