On Mar 13, 2013, at 10:07 PM, Jake Thomas Petroules <jake.petrou...@petroules.com<mailto:jake.petrou...@petroules.com>> wrote:
On Mar 13, 2013, at 1:43 PM, Bache-Wiig Jens <jens.bache-w...@digia.com<mailto:jens.bache-w...@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. The current android style is still not the answer to everything. What I am concerned about are if your desktop widget based apps end up looking like this when deployed to the device: https://bugreports.qt-project.org/browse/QTBUG-29565 To be fair, most of those glitches are of course related to the fact that you anyway should re-writte that UI from scratch to make it work better on a mobile layout, but it shows that a style alone cannot solve all those problems. 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. That is great news and I will look forward to seeing where this project ends up. It does sounds like we might have a reasonable way to solve many of those technical issues. I was not aware that you could separate the slider background from the handle so this does indeed make it sound feasible to me. But I still don't know how we will style more fundamental desktop concepts like dock widgets, mdi windows and spin boxes in a nice way. If the end result is that we have to make up all the pixmaps for those, it might be just as good have a pure pixmap based theme which would give us better performance and allow flawless integration with Designer and Creator 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. Unfortunately believe those will need separate solutions. I am of course already using QStyle for components on the desktop where performance and deployment size is not a major concern. But I was not also planning to also depend on the widgets module when delivering Qt Quick styling for IOS and Android as well. The current plan is to use QML for that. Using QStyle will force people to link against the widget module which could significantly increase the deployed application size and I don't see enough benefits to aim for that as the primary solution. 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. That remains to be seen. It sounds like you might have a good plan for solving the technical issues and the enthusiasm to bring the project all the way through. But It is not yet given that this should become the default style on IOS just yet. The appropriate place for initiating your project at the moment is the official qtstyleplugins repository: https://codereview.qt-project.org/#admin,project,qt/qtstyleplugins,info. If it turns out that it works great for widgets and feels polished over all, I am certainly ok with replacing Fusion with it. Fusion is anyway only meant as a placeholder or migration path and never as the goal itself. Regards, Jens
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
