[Development] Qt for iOS - iOSStyle

Jake Thomas Petroules jake.petroules at petroules.com
Tue Mar 12 00:17:37 CET 2013


On Mar 11, 2013, at 5:36 PM, Raul Metsma <raul at innovaatik.ee> wrote:

> here is one other solution
> http://docs.appcelerator.com/titanium/latest/
> javascript and native looking widgets under ios


Perhaps we could look into this.


On Mar 11, 2013, at 11:37 AM, Thiago Macieira <thiago.macieira at intel.com> wrote:

> On segunda-feira, 11 de março de 2013 07.41.02, Jake Thomas Petroules wrote:
>> 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.
> 
> The whole point is that you shouldn't use QtWidgets at all on mobile 
> platforms. Just don't.


I never said anything about widgets. I'm talking about QiOSStyle which would also be used by QtQuick.Controls just like Jens is doing now for the desktop.

QiOSStyle would power both widgets and QML controls, just like how the others work.


On Mar 11, 2013, at 3:54 PM, Rafael Roquetto <rafael.roquetto at kdab.com> wrote:

> Why not? I agree that QtQuick is usually the way to go for implementing mobile
> UI, but that doesn't exclude QtWidgets for any reasons a developer may wish to
> use it. When we did the BlackBerry port, we did implement a BlackBerry style,
> which could achieve native look and feel decently. This comes really handy
> when you are porting apps from the desktop.
> I think implementing a native iOS style wouldn't be hard. I don't know much
> about iOS development, but if what Jake says about being able to render
> controls to off-screen buffers, then it should be completely feasible.
> Of course, even better would be a set of QML components, but these are not
> mutually exclusive approaches.


My thoughts exactly.


Another thing is, there seem to be some private classes named like _UISearchBarAppearanceStorage in UIKit. Obviously, we can't use these in the final product, but perhaps we could play around with them during development in order to try and break controls down into their individual components (colors, images) which we can cache manually in QiOSStyle. There are messages such as: imageForIcon:state:, searchFieldBackgroundImageForState:, separatorImage, etc., which potentially look relevant. https://github.com/nst/iOS-Runtime-Headers


Also, this is about native control styling. So... let's focus on that and not turn this into a widgets vs QML debate. Like Rafael said, the two are not mutually exclusive.
-- 
Jake Petroules
Chief Technology Officer
Petroules Corporation · www.petroules.com
Email: jake.petroules at petroules.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20130311/4ca42fb1/attachment.html>


More information about the Development mailing list