[Development] Qt for iOS - iOSStyle

[Jake Thomas Petroules]

On Mar 13, 2013, at 1:43 PM, Bache-Wiig Jens <Jens.Bache-Wiig at digia.com> wrote:

> Exactly. Being able to do pixel perfect layouts within the Qt Quick designer is one of the arguments against an IOS QStyle implementation. I would like to be able to see and run my apps _exactly_ as they would look on the device, without having to test  and deploy on an IOS emulator through XCode.

By that logic we should get rid of QAndroidStyle, QGtkStyle, QWindowsStyle, etc. That's not an argument against an implementation merely existing. You can use the Fusion style for your project, and I'll use the iOS style for mine. There's no reason we can't have the best of both worlds.

Now on the technical issues, to use your own sentence against you, "it's not as bad as you think". You don't need to install event handlers within the style and do frame by frame updating hacks. All the iOS widgets inherit from UIControl, where you can set the highlighted (when you touch down), selected, and enabled/disabled states of a control; no need to fake input events to do it. Control styling is also more flexible than it seems. You can in some cases retrieve images for the individual parts of a control. A lot of the standard graphics can also be replaced with custom images, and through that functionality you can use trickery to do things like draw a slider's track and knob separately. The controls also provide some degree of metrics information (like text margins), and you can use trickery to do things like draw the backgrounds for left, middle, and right sections separately for a UISegmentedControl in selected and unselected states. Or the divider. I could even give you a slider with two knobs if you wanted. I've already started writing code for this and have been pleased with the results so far.

Also, I just have to respond to this: "it completely falls apart when you try to render something slightly complex like a slider, unless you update the position of the native handle and re-grab it on each frame" The second part of your sentence answers the first. I don't see how that's a problem at all. That is essentially the same way any styling API works - each frame, you tell it to render. Any internal state it might update as part of that process is not your concern. I know this is not the case but HITheme could be using a NSSlider internally, for example, and you'd never know it.

So, to summarize:

As Morten said, "The way to prove us wrong is of course to step up and implement (and maintain) such a style.". Therefore, I will implement and maintain QiOSStyle. Of course any help would be appreciated as well.

Now, I want to stress this fact: I'm trying to support everyone's use cases, not exclude anyone at the expense of others. QStyle is used by both widgets AND QtQuick.Controls. All of these use cases are perfectly valid: widgets + custom style, widgets + native style, QML + custom style, QML + native style.

So, the only thing left to say is that I hope the issue is not whether QiOSStyle is welcome in QtGui at all, but simply whether it can be technically achieved and whether there is someone to do the work. If it's the latter, then we're all set and can end the discussion, since I will do it. Otherwise, QiOSStyle will be on GitHub. I'd much prefer it to be upstreamed. 

PS - To everyone debating the merits of widgets vs QML in general: this thread is about the implementation of an iOS QStyle to draw native-looking controls for QWidgets AND QtQuick.Controls. Could you please continue those discussions in a different thread?
-- 
Jake Petroules
Chief Technology Officer
Petroules Corporation · www.petroules.com
Email: jake.petroules at petroules.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20130313/ce65b62d/attachment.html>