[Development] Qt for iOS - iOSStyle

[Bache-Wiig Jens]

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.

> 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.

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.

> Same idea with iOS. It has a theme. That theme should be adhered to in order to maintain the same level of quality and refinement that Qt applications are able to achieve on other platforms.
> 
> Apple should give us headers and documentation for CoreUI.framework and the _UIClassNameAppearanceStorage classes in UIKit. That would make life a bit easier. :)

Yes, if there was a public theming API on IOS I would certainly want to support it. But you will still be able to make great IOS apps using Qt Quick even if they don't add one.

Regards,
Jens