[Development] Future of Qt Quick 1 in Qt 5

André Somers andre at familiesomers.nl
Mon May 11 12:00:08 CEST 2015

Simon Hausmann schreef op 11-5-2015 om 09:21:
> On Saturday, May 09, 2015 09:59:18 PM Andre Somers wrote:
>> On 8-5-2015 18:47, Hausmann Simon wrote:
>>> Hi,
>>> If the public API would allow you to implement what the folks at KDAB did
>>> at http://www.kdab.com/creating-pdf-qtquick-2-scene-slideviewer/ ‎, would
>>> that help your use case?
>> What they basicaly did was reimplement the Quick elements they were
>> using, if I understood it right from an earlier time I read that blog,
>> and then solve all kinds of issues with rendering that were already
>> solved inside Qt itself... So, it comes down to implementing the
>> elements of Quick 1 on your own again for the elements you need, or
>> something close to it. It is what I called "major work" in my first
>> reply. And indeed: I guess doing this requires heavy use of private API.
>> So far, QML and Quick are not all that friendly for C++-side extensions...
> This doesn't match my understanding of what they have done at all. I
> understand their article as having basically "visited" all items in the scene
> and having had to use private API to access the data so that they can
> implement printing outside of Qt Quick, but still using standard Qt Quick
> elements.
> But perhaps I misread it. What is your understanding after re-reading it?

Ok, indeed, you're right. They didn't re-implement the actual items, 
they "just" reimplemented everything needed in those items to render 
them. Indeed: visiting each item and then figuring out how to render it 
completely from scratch. But they only did that for a handfull of items, 
and not taking into account all possibly relevant properties because 
they didn't use them as much.
>> I read about an effort of a different rendering backend for Quick a
>> while ago done by Digia at that time that sounded like it could work to
>> solve the issue, but that was not freely available to take a look at so
>> I don't know for sure it would fit the use case.
> In theory it would be a fit - at least in terms of being able to get all the
> right data passed down to the print engine to do high quality text printing.
> Anyway, could you elaborate a bit on your printing needs?
> Do you need pagination?
Yes, we do that, but in our case we don't need dynamic pages. We know 
for each report how pages there are, and we created a Page object to 
represent it. Each page object gets placed below the previous page in 
the scene with a small spacing, so a preview looks natural. In an actual 
printing run, we simply do a render of the rect for each page we need to 
appear in the print output.
> How about text flow - do you need to change the line breaking in order for
> your text to appear?
Not sure what you mean here.  We do use text layout with line breaking 
and the likes, and I have had to duplicate some features from Quick2's 
Text item too (automatic adaptation of font size to make contents fit, 
for instance).
> With regards to images: Do you have high-res versions of images available for
> print and lower res images for screen display?
We have some custom content (rendered graphs) that indeed are 
target-resolution-aware. Plain images are not; the few simple images we 
have are simply scaled.
> What about the level of detail: Does your print-out contain _exactly_ the same
> content as on the screen or are there more or less details? (I'm thinking
> about borders, transparency, etc.)
See above: yes, we do. We have measures to make sure that for instance a 
line can be quite thin on a high-resolution device, but it doesn't 
disapear when rendered on a low resolution one (like the screen).


More information about the Development mailing list