[Development] Qt for iOS - iOSStyle
Rafael Roquetto
rafael.roquetto at kdab.com
Tue Mar 12 12:23:03 CET 2013
On Tue, Mar 12, 2013 at 07:56:33AM +0000, Bache-Wiig Jens wrote:
>
> On Mar 11, 2013, at 12:41 PM, Jake Thomas Petroules <jake.petroules at petroules.com> wrote:
>
> > By the way, I don't know if you saw my comments on your "Qt for iOS Preview" blog post, but...
> >
> > You stated that because there is no HITheme-like API on iOS, that creating QiOSStyle would be "not possible".
> >
> > However, we can render any UIView into a buffer using [UIView drawInRect:] which we should utilize to provide as much support for native styling as that allows us to.
>
> This is not a replacement for a styling API. What you are proposing is equivalent to creating a native IOS widget behind the scenes and taking screenshots of it. It is a hack and it can only work for a few cases. It barely works for buttons (but not segmented ones or tabs) provided you hard code text margins which could change at any point in the future. It will not give you mouseover/hover states without faking input events. And 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.
I must disagree on this one. If you consider installing event handlers within
the style, and and frame-by-frame updating hacks, then yes, it is a hack. But
that's what we have for now, unfortunately.
>
> > Jens claimed on the blog that the native look and feel matters less in the mobile world because each app is fullscreen. I agree that it matters less, but I disagree that it matters little enough for us to ignore it. I'd much rather use real iOS-looking controls than simply slap on Fusion. Apple users are commonly noted to be extremely particular about very small UI defects. If we spend the time to go "oh, the text alignment in QLineEdit is one pixel too low on OS X", and actually take the time to fix it, iOS should be no different.
>
> What I was replying to was your following statement on Mortens blog:
>
> "Without the ability to draw native controls, developing user interfaces in Qt becomes useless except for games with totally custom UI."
>
> Which I simply can not leave uncommented. I _never_ said style does not matter and I certainly never implied that it was something we should ignore. What I did say was "It is not as bad as you make it out to be. "
>
> > So... why can't we use [UIView drawInRect:]? Qt 5 uses the same approach with NSScroller on OS X for drawing the Lion/ML scrollbars (10c6f015f45092040c281bb90a65179f598a00b1).
> >
> > Native styling is important wherever you are. Not everything is a fancy web app or fancy QML game with custom graphics. Although I've not tested it extensively, Qt seems to have a completely functional style implementation for Android that look like native controls for the theme my phone uses, and the themes that other phones use, on those phones. We wouldn't want Qt/Android apps to look the same on every device, or like something else.
>
> Have you actually seen a real-world QWidget based example compiled android that truly looks and feels native? I am genuinely curious about how far this style will get you and I haven't found anything resembling even a screen shot on Google. Add this to the fact that Android actually has a public styling API and Apple does not.
>
> My point is that if we already know that we cannot give it a 100% native interface using QStyle, it is not worth creating a half baked one using lots of time, hacks and resources. Using Fusion style with some transient scroll bar and retina fixes will make it nearly trivial to port existing QWidget apps and layouts to IOS with a minimum of effort. The developers that do not want to invest time into making a proper touch based QML interface are not likely to care much about the look of their sliders and even if they do, adding a few IOS-style buttons into the mix is not going to make that desktop app suddenly look native. I find it more likely that it will enter the infamous "uncanny valley" and generate pointless bug reports against their apps.
Do we already know we cannot give it a 100% native look? I don't, and while I
am not saying we can, I would believe it is possible. Another option is using
a pixmap based style, or a mix of both. Well in the end, it will be a pixmap
based style anyway, except that if necessary, instead of rendering stuff on
the fly, we could use pre-loaded pixmaps together whenever it makes sense.
>
> For Qt Quick, the situation is different. You can already make your app look as native on IOS as you want to. Just download one of the many photoshop UI kits and ship your app with those pixmaps. That is what a large part of the IOS developers are already doing and one of the reasons Apple is so conservative about changing it's look and feel. Apple has not cared about their apps looking native for a long time. Have you seen their "Newsstand", "Calendar", "Notes,", "Clock", "Photo Booth", "Reminders", "Game Center" and "Calendar Apps"? If you haven't I suggest you look them up. There is hardly a single native control to spot anywhere. Many of the best known apps on IOS actually try hard to look _different_ in order to differentiate themselves from the 500 million apps already out there. Native look and feel is _not_ a silver bullet that makes an IOS app a success on the store. It might not even be beneficial if the alternative looks better.
>
> While I hope we would be able to ship a style for Qt Quick Controls that look like IOS, I am intrigued by the idea of creating a good looking cross platform design language for mobile Qt apps that look good on more than one platform and doesn't even try to fake Apple. Look at what Google has done recently. They have created a new google design aesthetic and use the same on both Android and IOS. It is distinctly google. It does not use the native look and feel, yet somehow they are still almost universally getting great reviews on their fresh new aesthetics on IOS:
>
> http://www.gizmodo.com.au/2012/12/google-maps-for-ios-review-maps-done-right/
>
> http://www.netmagazine.com/features/big-question-what-do-you-think-googles-new-design-strategy
>
> Developing this way, it would be possible to design good looking apps cross-platform and give the developer complete control over the end product. It would remove the need to test the app in a slow emulator that only runs on mac. People will also not file bug reports about pixels that are slightly off. They only do that when you try to fake something.
Another good example of iOS app that does not quite follow the native UI is
LinkedIn. I really like it, and I agree with you when you say some design
alternatives can actually look even better than the stock native style based
ones. But I am assuming this is not the point in this discussion - the point
is: is it possible to implement a QStyle based iOS style? I would go for yes.
Now, is there enough manpower and does it make sense? I don't know, then it's
up to whoever will (not) be doing it.
There might be a dozens of reasons not to go down that road - complexity, lack
of manpower or whatever may turn up. But assuming it will look half baked and
place that as a main reason makes me scratch my head.
--
Rafael Roquetto | rafael.roquetto at kdab.com | Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - Qt Experts - Platform-independent software solutions
More information about the Development
mailing list