On Mar 11, 2013, at 12:41 PM, Jake Thomas Petroules 
<jake.petrou...@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

_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Reply via email to