On Monday 10 Feb 2014 17:07:11 Shaw Andy wrote: > > Since the feature freeze is on the 14th I have been eagerly awaiting the > changes that have been indicated already have been done so I can carry on > testing. Have I missed some updates or something? I am concerned because I > know how many people use the printing and we need to try and get these > changes tested and fixed where necessary in good time for the final so the > transition is not really noticed by the users. So is there any update on > these patches or should we consider waiting until Qt 5.4 to ensure they are > all ready correctly?
Sorry, needed to wait until the full stack of changes had been completed and integrated before pushing. The revised patches are up for review, I'm not sure we'll get it done in time, but it's worth a crack, otherwise I'll have to slog through the old code again fixing all the bugs I found for 5.3, only to replace the code again in 5.4. Apologies for the rebase, but it was needed. Main changes are: * Removed QPageMargins and added QMarginsF instead * QPageLayout uses QMarginsF and now has an enum and attribute for QPageLayout::Units to track what units are used for all the margins. Turns out while this complicates some public api, it also simplifies the way the class is used in real code. * QPageSize also has a QPageSize::Unit, that duplicates QPageLayout::Unit but I couldn't find a nice place to put a common enum. * Both QPageLayout::Unit and QPageSize::Unit don't have a value for DevicePixels anymore as it doesn't make sense. That simplifies api in a number of places by removing the resolution parm. The main issues outstanding I see: * Mac issue with PMPaper: in my testing I need the extra PMRetain to prevent a crash, but Morten gets a memory leak with it, and Andy reports it crashes for him anyway. Try the latest code, if the issue still persists I'll look for an alternative way of doing things. * Win is reported as being slow, that's an issue with the old code too, but the new code may make it slightly slower. It's due to the DC being refreshed every time a setting is changed, which is plain slow. Once the new code is in and handling the layout calculations, I think it's possible to remove the DC refresh at every step and just init the DC when start() is called. If anyone else wants to test this, there's a few things you can run besides the auto tests: examples/widgets/richtex/textedit tests/manual/dialogs tests/manual/qprintdevice_dump Cheers! John. _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
