On Mar 13, 2013, at 1:43 PM, Bache-Wiig Jens <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.
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.petrou...@petroules.com
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
