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.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. 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.roque...@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 _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
