Re: [Development] Qt for iOS - iOSStyle
On 2013/03/19 1:57 AM, Jake Thomas Petroules wrote: Not every app should be styled native. Not every app should be styled custom. Some should use a combination of both. It all depends on what's appropriate for the situation at hand. All I'm asking is that people recognize that we need a balance here. We can provide both options. If there's someone willing to put in the work, of course it would be fantastic to be able to render Qt widgets so that they look like iOS controls, there's no question about that. Whether many/any people would use it is another question, which remains to be seen (see chicken/egg). So what's the problem with making iOS styled QtWidgets? They will never ever look and behave the same as the native components (maybe a button, but how about a list view? And what is a combo box on iOS?). They will definitely look the same. As for behave, that's a little harder but it can still be done. Not sure if I can see the value in creating pixel perfect widgets with exactly the same behaviour as the native widgets. Just use the native widgets (with a QtWidget wrapper) and job done. I can see the attraction in making Qt widgets look like they use the same design language as UIKit widgets. Almost everything looks wrong. The UISwitch text is misaligned and the fonts on the toolbars look strange. Smells like an attempted custom drawing. AFAIK, it's a port of Symbian Qt Quick components to iOS. I don't know much more about it, or what its author's plans are. There's a problem with fonts on iOS. AFAIK you're not allowed to use the (private) font that Apple uses for its UI in your apps. If you did use that font, you'd have to fool Apple's review board into believing you were using native widgets... ;) Again, I've already started on QIosStyle and it's working pretty nicely. https://codereview.qt-project.org/#change,51167 Once I've uploaded some of the functionality I've been working on, I encourage you to give it a try. It might make you change your mind about QIosStyle being a waste of time. :) I'd be very interested in seeing what you've done, and would be more than happy to help you. I meant a waste of my time (and really not so much a waste as it being a very low priority task in terms of all that still is needed)... ;) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt for iOS - iOSStyle
On Mar 18, 2013, at 8:26 AM, Mediator Software i...@mediator-software.com wrote: In the real world, Qt on iOS is being used primarily to port existing QtWidget applications to the iPad, not to write new ones (nor to do anything on any other iOS platforms). There is a single customer using QML on iOS, once again porting an existing app. My opinion is that an iOS style for QtWidgets would be a waste of time One man's trash, another man's treasure. Why? Judging from existing Qt apps on iOS, noone is using platform styling anyway. They should. All existing ported apps have custom UIs developed with QtWidgets. They don't look like iOS, fusion or anything else. They have their own UI. Which generally looks out of place and terrible. This includes Apple's stock apps like Notes. I hope Jony Ive gets rid of all this skeumorphic design. See, people argue that there are many Apple stock apps that use totally custom styling, therefore everyone should do that, screw native controls, they don't matter. However there's a decent handful of stock apps that use almost exclusively native styling: Settings, Phone, Messages, Mail, Calendar, Contacts, Safari and at least in my opinion those are some of the most well designed and best looking apps on the system. Not every app should be styled native. Not every app should be styled custom. Some should use a combination of both. It all depends on what's appropriate for the situation at hand. All I'm asking is that people recognize that we need a balance here. We can provide both options. The same goes for QML, but there I can see a use for iOS QML components. So can I. I may work on this in the future as well. Right now the focus is widgets. What we really need a new styling system that can act as a backend for both QStyle/widgets and QML. So what's the problem with making iOS styled QtWidgets? They will never ever look and behave the same as the native components (maybe a button, but how about a list view? And what is a combo box on iOS?). You're safer with a custom UI in that case because Apple will fail you if you confuse the user (if it looks like a UIKit widget it must behave *exactly* like a UIKit widget). They will definitely look the same. As for behave, that's a little harder but it can still be done. A combo box is a UIPickerView. There's no rule that requires a QComboBox to look like a rectangle with a down arrow that pops up a menu when you click it. I think substituting the appearance/behavior of a UIPickerView for QComboBox makes sense as their functional equivalence is roughly the same. There are plenty of comments in the Qt documentation that make note of platform specific exceptions, or a property's lack of effect on one platform or another. iOS may have more of these than other platforms. That's OK. Sometimes it would be nice to use actual UIKit controls in Qt applications (eg. UIWebView), but have them behave like Qt widgets (signals/slots etc.). For Qt4iOS on Qt4 (and soon on Qt5), custom QWidget wrappers have been developed for some UIKit controls. This gives you the *actual* UIKit control (pixel perfect with its exact behaviour), but let's you use Qt layouts/logic etc. IMHO that's the way forward for Qt widget apps that look like UIKit apps. I intend to do something similar with QML (embedding a UIKit control in a QML item). There's no reason why wrappers (C++ or QML) couldn't be developed for all UIKit widgets. There's not that many of them. Yes, this could certainly be useful. It's one option, not the only one. I'd actually like to see more of these on desktop platforms -- especially Mac, since Qt has no QSearchField or QSegmentedControl (we should!), which are quite nice. IMHO, it would be most useful to make QtQuick components for iOS. Someone has already made a set, but it's unclear what their plans are. You can see a demo video here: https://docs.google.com/file/d/0B2qhh3gqs-wzaEJvV3A4TjVTQWc/edit?pli=1 https://docs.google.com/file/d/0B2qhh3gqs-wzXzRlNmdUN0thcTA/edit Almost everything looks wrong. The UISwitch text is misaligned and the fonts on the toolbars look strange. Smells like an attempted custom drawing. Again, I've already started on QIosStyle and it's working pretty nicely. https://codereview.qt-project.org/#change,51167 Once I've uploaded some of the functionality I've been working on, I encourage you to give it a try. It might make you change your mind about QIosStyle being a waste of time. :) -- Jake Petroules Chief Technology Officer Petroules Corporation · www.petroules.com Email: jake.petrou...@petroules.com___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt for iOS - iOSStyle
On segunda-feira, 18 de março de 2013 19.57.41, Jake Thomas Petroules wrote: On Mar 18, 2013, at 8:26 AM, Mediator Software i...@mediator-software.com wrote: In the real world, Qt on iOS is being used primarily to port existing QtWidget applications to the iPad, not to write new ones (nor to do anything on any other iOS platforms). There is a single customer using QML on iOS, once again porting an existing app. My opinion is that an iOS style for QtWidgets would be a waste of time One man's trash, another man's treasure. Why? Judging from existing Qt apps on iOS, noone is using platform styling anyway. They should. No, they shouldn't, not now anyway. If your style work is successful and looks good, then we can say that people should use the widgets. But right now, they definitely should stay away from them! Applications will default to the Fusion style, which is very touch- unfriendly. In any case, we've been trying this for 4 years. QWidgets simply don't work on mobile environments. It was hard enough on platforms that we could reasonably control (the three Nokia platforms). It will be that much more difficult on a platform where we have *no* say in how things behave, has extremely picky users and an arbitrary review before being allowed. What we really need a new styling system that can act as a backend for both QStyle/widgets and QML. Agreed. The question is to find what is common between those. There's almost nothing. Once I've uploaded some of the functionality I've been working on, I encourage you to give it a try. It might make you change your mind about QIosStyle being a waste of time. :) I appreciate your work and wish you success. But please be prepared to accept failure too. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt for iOS - iOSStyle
Me again. I thought I'd announce that I've pushed the first QIosStyle commit to Gerrit: https://codereview.qt-project.org/#change,51167 I will be doing all work on the class here in the public eye until it is done and ready to be merged (hopefully before 5.2 at the latest, 5.1 if we're lucky). I'd greatly appreciate any feedback and testing during the development process. I've added a few of you as reviewers who are obviously relevant, and another person who expressed interest in testing the functionality. Back to the QStyle and UIKit documentation I go. -- Jake Petroules Chief Technology Officer Petroules Corporation · www.petroules.com Email: jake.petrou...@petroules.com___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt for iOS - iOSStyle
Op 13-3-2013 18:43, Bache-Wiig Jens schreef: Exactly. Being able to do pixel perfect layouts within the Qt Quick designer is one of the arguments against an IOS QStyle implementation. I would like to be able to see and run my apps _exactly_ as they would look on the device, without having to test and deploy on an IOS emulator through XCode. In that case, this whole discussion is moot. You are not going to get see your apps _exactly_ as they would look on the device, if only because of the differences in resolution between your systems screen and the one on your device. Using QML has the exact same problems there as using widgets. André -- You like Qt? I am looking for collegues to join me at i-Optics! ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt for iOS - iOSStyle
On Mar 13, 2013, at 10:07 PM, Jake Thomas Petroules jake.petrou...@petroules.com wrote: So, the only thing left to say is that I hope the issue is not whether QiOSStyle is welcome in QtGui at all, but simply whether it can be technically achieved and whether there is someone to do the work. If it's the latter, then we're all set and can end the discussion, since I will do it. Otherwise, QiOSStyle will be on GitHub. I'd much prefer it to be upstreamed. We think that the Qt Style Plugins repository is a good place for QiOSStyle, together with the other optional Qt Styles. Would that work for you? Morten Qt Style Plugins : https://codereview.qt-project.org/#admin,project,qt/qtstyleplugins,info http://qt.gitorious.org/qt/qtstyleplugins ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt for iOS - iOSStyle
On Mar 13, 2013, at 10:07 PM, Jake Thomas Petroules jake.petrou...@petroules.commailto:jake.petrou...@petroules.com wrote: On Mar 13, 2013, at 1:43 PM, Bache-Wiig Jens jens.bache-w...@digia.commailto:jens.bache-w...@digia.com wrote: Exactly. Being able to do pixel perfect layouts within the Qt Quick designer is one of the arguments against an IOS QStyle implementation. I would like to be able to see and run my apps _exactly_ as they would look on the device, without having to test and deploy on an IOS emulator through XCode. By that logic we should get rid of QAndroidStyle, QGtkStyle, QWindowsStyle, etc. That's not an argument against an implementation merely existing. You can use the Fusion style for your project, and I'll use the iOS style for mine. There's no reason we can't have the best of both worlds. The current android style is still not the answer to everything. What I am concerned about are if your desktop widget based apps end up looking like this when deployed to the device: https://bugreports.qt-project.org/browse/QTBUG-29565 To be fair, most of those glitches are of course related to the fact that you anyway should re-writte that UI from scratch to make it work better on a mobile layout, but it shows that a style alone cannot solve all those problems. Now on the technical issues, to use your own sentence against you, it's not as bad as you think. You don't need to install event handlers within the style and do frame by frame updating hacks. All the iOS widgets inherit from UIControl, where you can set the highlighted (when you touch down), selected, and enabled/disabled states of a control; no need to fake input events to do it. Control styling is also more flexible than it seems. You can in some cases retrieve images for the individual parts of a control. A lot of the standard graphics can also be replaced with custom images, and through that functionality you can use trickery to do things like draw a slider's track and knob separately. The controls also provide some degree of metrics information (like text margins), and you can use trickery to do things like draw the backgrounds for left, middle, and right sections separately for a UISegmentedControl in selected and unselected states. Or the divider. I could even give you a slider with two knobs if you wanted. I've already started writing code for this and have been pleased with the results so far. Also, I just have to respond to this: 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 The second part of your sentence answers the first. I don't see how that's a problem at all. That is essentially the same way any styling API works - each frame, you tell it to render. Any internal state it might update as part of that process is not your concern. I know this is not the case but HITheme could be using a NSSlider internally, for example, and you'd never know it. So, to summarize: As Morten said, The way to prove us wrong is of course to step up and implement (and maintain) such a style.. Therefore, I will implement and maintain QiOSStyle. Of course any help would be appreciated as well. That is great news and I will look forward to seeing where this project ends up. It does sounds like we might have a reasonable way to solve many of those technical issues. I was not aware that you could separate the slider background from the handle so this does indeed make it sound feasible to me. But I still don't know how we will style more fundamental desktop concepts like dock widgets, mdi windows and spin boxes in a nice way. If the end result is that we have to make up all the pixmaps for those, it might be just as good have a pure pixmap based theme which would give us better performance and allow flawless integration with Designer and Creator as well. Now, I want to stress this fact: I'm trying to support everyone's use cases, not exclude anyone at the expense of others. QStyle is used by both widgets AND QtQuick.Controls. All of these use cases are perfectly valid: widgets + custom style, widgets + native style, QML + custom style, QML + native style. Unfortunately believe those will need separate solutions. I am of course already using QStyle for components on the desktop where performance and deployment size is not a major concern. But I was not also planning to also depend on the widgets module when delivering Qt Quick styling for IOS and Android as well. The current plan is to use QML for that. Using QStyle will force people to link against the widget module which could significantly increase the deployed application size and I don't see enough benefits to aim for that as the primary solution. So, the only thing left to say is that I hope the issue is not whether QiOSStyle is welcome in QtGui at all, but simply whether it can be technically achieved and
Re: [Development] Qt for iOS - iOSStyle
I really don't understand why QtWidgets are not suitable for mobile plataforms. What is the technicall reason ? Following the Qt code once deploy everywhere I have apps with pratically the same code for desktop, symbian and Blackberry. Sometimes the requirements for technicall / engineering apps are just to have minimal, simple, accurate, funtional app interface instead of a shiny, full of glow interface, and thats perflectly achievable with Widgets. As for iOS style, I think it could be done for mobile the same way it is done for desktop, even if it's not 100% native. João de Deus De: Thiago Macieira thiago.macie...@intel.com Para: development@qt-project.org Enviadas: Segunda-feira, 11 de Março de 2013 15:37 Assunto: Re: [Development] Qt for iOS - iOSStyle 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. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt for iOS - iOSStyle
On Wednesday 13 March 2013 04:46:43 joao morgado wrote: I really don't understand why QtWidgets are not suitable for mobile plataforms. What is the technicall reason ? Following the Qt code once deploy everywhere I have apps with pratically the same code for desktop, symbian and Blackberry. Sometimes the requirements for technicall / engineering apps are just to have minimal, simple, accurate, funtional app interface instead of a shiny, full of glow interface, and thats perflectly achievable with Widgets. As for iOS style, I think it could be done for mobile the same way it is done for desktop, even if it's not 100% native. Indeed - even though there a some issues to be taken into account (screensize etc). I fully agree with you. I have a (huge) application developed for any kind of device - with a really long product livecycle - which was initially designed to support multiple screen sizes as well as different mobile devices (tablets and such) and I see absolutely no reason for not using this approach. Especially in case where the usability and way of usage are defined off the default road: i.e. having an application private style and usage metaphors. Frank ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt for iOS - iOSStyle
On Mar 13, 2013, at 12:58 PM, Frank Hemer fr...@hemer.org wrote: On Wednesday 13 March 2013 04:46:43 joao morgado wrote: I really don't understand why QtWidgets are not suitable for mobile plataforms. What is the technicall reason ? Following the Qt code once deploy everywhere I have apps with pratically the same code for desktop, symbian and Blackberry. Sometimes the requirements for technicall / engineering apps are just to have minimal, simple, accurate, funtional app interface instead of a shiny, full of glow interface, and thats perflectly achievable with Widgets. As for iOS style, I think it could be done for mobile the same way it is done for desktop, even if it's not 100% native. Indeed - even though there a some issues to be taken into account (screensize etc). I fully agree with you. I have a (huge) application developed for any kind of device - with a really long product livecycle - which was initially designed to support multiple screen sizes as well as different mobile devices (tablets and such) and I see absolutely no reason for not using this approach. Especially in case where the usability and way of usage are defined off the default road: i.e. having an application private style and usage metaphors. Frank@ Note that you _can_ use QtWidgets if you want to. This works, and we support it. If this solves things for you, all is good. But writing fluid interfaces using widgets is time consuming and laborious. For sure, some developers don't care about creating fluid interfaces. That simply means they have a relaxed approach to native look and feel for their app in the first place. To me it looks like app developers in iOS wants their apps to be fluid and shiny. And not only do we want Qt/iOS to be a framework for writing such applications, we want it to be the best choice on the market. And we simply think QML is a better technology to meet those needs, which explains why we don't focus the iOS development around styling up widgets. How to best support QML controls with a style that blends nicly into iOS, is yet to be decided. -Richard (Qt/iOS team) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt for iOS - iOSStyle
On quarta-feira, 13 de março de 2013 00.51.05, André Pönitz wrote: I'll try hard to abstain from anything resembling irony or sarcasm. I just want to carry on this theoretical discussion based on purely hypothetical facts. I'd ask you kindly to either read all, or nothing. Hi André Without agreeing or disagreeing to your arguments, nor even emitting an opinion on them, let's just take them for granted and analyse the situation. If you're right, we need a powerful C++ API for doing what currently can only be done in QML and is being proposed to be done only in QML. I'm arguing we have no such API (read: it's not QtWidgets!). So we have two options: create and develop it, or not. The question is: if we need to implement it, do we need to implement it before the QML API? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt for iOS - iOSStyle
To Richard: What your saying makes perfect sense to me, and whatever solution your team comes up with, for iOS style, I'm sure it will be handsome, (it's Qt we're talking after all :) ). Just some toughts from an humble indie developer: regarding QML iOS style (and QML in general), I would like to see basic components (buttons, sliders, edit boxes, lists, ) working out of the box in QML Designer. I admit QML sintaxe looks easy compare to C++, but to me (and to many other developers) it's a pain to have to code QML basic stuff like buttons, etc..., by hand, something that is done nicely and beautifully in just a few minutes in Widget Designer, just by dragging and droping. Last time I checked QML Designer was terrible broken, I admit I havent checked latest Qt5.xx version to see if that changed. Regarding QML in general, another think that puzzles me a lot is, I keep seeing coming different set of components: harmattan, symbian, the desktop components, Jolla Silica, ... That's ok, but here is code once deploy every where ? Technically would it be hard to ship standard QML components working for all plataforms (even if we would have to make small adaptations for each plataform) ? This lack of standard QML components, to me (and possible many other developers) is what stopping me from head jumpig into the QML wagon . João de Deus De: Gustavsen Richard richard.gustav...@digia.com Para: development development@qt-project.org Enviadas: Quarta-feira, 13 de Março de 2013 14:32 Assunto: Re: [Development] Qt for iOS - iOSStyle On Mar 13, 2013, at 12:58 PM, Frank Hemer fr...@hemer.org wrote: On Wednesday 13 March 2013 04:46:43 joao morgado wrote: I really don't understand why QtWidgets are not suitable for mobile plataforms. What is the technicall reason ? Following the Qt code once deploy everywhere I have apps with pratically the same code for desktop, symbian and Blackberry. Sometimes the requirements for technicall / engineering apps are just to have minimal, simple, accurate, funtional app interface instead of a shiny, full of glow interface, and thats perflectly achievable with Widgets. As for iOS style, I think it could be done for mobile the same way it is done for desktop, even if it's not 100% native. Indeed - even though there a some issues to be taken into account (screensize etc). I fully agree with you. I have a (huge) application developed for any kind of device - with a really long product livecycle - which was initially designed to support multiple screen sizes as well as different mobile devices (tablets and such) and I see absolutely no reason for not using this approach. Especially in case where the usability and way of usage are defined off the default road: i.e. having an application private style and usage metaphors. Frank@ Note that you _can_ use QtWidgets if you want to. This works, and we support it. If this solves things for you, all is good. But writing fluid interfaces using widgets is time consuming and laborious. For sure, some developers don't care about creating fluid interfaces. That simply means they have a relaxed approach to native look and feel for their app in the first place. To me it looks like app developers in iOS wants their apps to be fluid and shiny. And not only do we want Qt/iOS to be a framework for writing such applications, we want it to be the best choice on the market. And we simply think QML is a better technology to meet those needs, which explains why we don't focus the iOS development around styling up widgets. How to best support QML controls with a style that blends nicly into iOS, is yet to be decided. -Richard (Qt/iOS team) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt for iOS - iOSStyle
On Mar 13, 2013, at 5:07 PM, joao morgado joaodeusmorg...@yahoo.commailto:joaodeusmorg...@yahoo.com wrote: To Richard: What your saying makes perfect sense to me, and whatever solution your team comes up with, for iOS style, I'm sure it will be handsome, (it's Qt we're talking after all :) ). Just some toughts from an humble indie developer: regarding QML iOS style (and QML in general), I would like to see basic components (buttons, sliders, edit boxes, lists, ) working out of the box in QML Designer. I admit QML sintaxe looks easy compare to C++, but to me (and to many other developers) it's a pain to have to code QML basic stuff like buttons, etc..., by hand, something that is done nicely and beautifully in just a few minutes in Widget Designer, just by dragging and droping. Last time I checked QML Designer was terrible broken, I admit I havent checked latest Qt5.xx version to see if that changed. Exactly. Being able to do pixel perfect layouts within the Qt Quick designer is one of the arguments against an IOS QStyle implementation. I would like to be able to see and run my apps _exactly_ as they would look on the device, without having to test and deploy on an IOS emulator through XCode. Regarding QML in general, another think that puzzles me a lot is, I keep seeing coming different set of components: harmattan, symbian, the desktop components, Jolla Silica, ... That's ok, but here is code once deploy every where ? Technically would it be hard to ship standard QML components working for all plataforms (even if we would have to make small adaptations for each plataform) ? This lack of standard QML components, to me (and possible many other developers) is what stopping me from head jumpig into the QML wagon . As you might already be aware of we have been working on a project formerly known as desktop components. The project was recently renamed to Qt Quick Controls and as you might have guessed, the main reason was that we intend to make the same API and controls also work for touch and phone platforms. Yes, you can think of them as widgets for qt quick. For 5.1 we still have the main focus on providing most of the missing gaps we have in order to enable full scale desktop development. This includes QML enablers for Menu, Layouts, Dialogs, Widgets/Controls, Splitters, Actions, Shortcuts etc. But in 5.2 we are planning to focus on providing support for touch-based platforms such as IOS and android. The main difference between the Qt Quick Controls and the other component sets is of course that they will be built into Qt itself and they will work across platforms. Regards, Jens ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt for iOS - iOSStyle
Thank you for all that info, that roadmap to Qt5.2 sounds good. So we will be able to use Qt quick componentes for interfaces and do the apps core development in C++ or javascript right ? I'm sorry if this is becoming off-topic Regards João de Deus De: Bache-Wiig Jens jens.bache-w...@digia.com Para: joao morgado joaodeusmorg...@yahoo.com Cc: Gustavsen Richard richard.gustav...@digia.com; development development@qt-project.org Enviadas: Quarta-feira, 13 de Março de 2013 17:43 Assunto: Re: [Development] Qt for iOS - iOSStyle On Mar 13, 2013, at 5:07 PM, joao morgado joaodeusmorg...@yahoo.com wrote: To Richard: What your saying makes perfect sense to me, and whatever solution your team comes up with, for iOS style, I'm sure it will be handsome, (it's Qt we're talking after all :) ). Just some toughts from an humble indie developer: regarding QML iOS style (and QML in general), I would like to see basic components (buttons, sliders, edit boxes, lists, ) working out of the box in QML Designer. I admit QML sintaxe looks easy compare to C++, but to me (and to many other developers) it's a pain to have to code QML basic stuff like buttons, etc..., by hand, something that is done nicely and beautifully in just a few minutes in Widget Designer, just by dragging and droping. Last time I checked QML Designer was terrible broken, I admit I havent checked latest Qt5.xx version to see if that changed. Exactly. Being able to do pixel perfect layouts within the Qt Quick designer is one of the arguments against an IOS QStyle implementation. I would like to be able to see and run my apps _exactly_ as they would look on the device, without having to test and deploy on an IOS emulator through XCode. Regarding QML in general, another think that puzzles me a lot is, I keep seeing coming different set of components: harmattan, symbian, the desktop components, Jolla Silica, ... That's ok, but here is code once deploy every where ? Technically would it be hard to ship standard QML components working for all plataforms (even if we would have to make small adaptations for each plataform) ? This lack of standard QML components, to me (and possible many other developers) is what stopping me from head jumpig into the QML wagon . As you might already be aware of we have been working on a project formerly known as desktop components. The project was recently renamed to Qt Quick Controls and as you might have guessed, the main reason was that we intend to make the same API and controls also work for touch and phone platforms. Yes, you can think of them as widgets for qt quick. For 5.1 we still have the main focus on providing most of the missing gaps we have in order to enable full scale desktop development. This includes QML enablers for Menu, Layouts, Dialogs, Widgets/Controls, Splitters, Actions, Shortcuts etc. But in 5.2 we are planning to focus on providing support for touch-based platforms such as IOS and android. The main difference between the Qt Quick Controls and the other component sets is of course that they will be built into Qt itself and they will work across platforms. Regards, Jens___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt for iOS - iOSStyle
On Mar 13, 2013, at 1:43 PM, Bache-Wiig Jens jens.bache-w...@digia.com wrote: Exactly. Being able to do pixel perfect layouts within the Qt Quick designer is one of the arguments against an IOS QStyle implementation. I would like to be able to see and run my apps _exactly_ as they would look on the device, without having to test and deploy on an IOS emulator through XCode. By that logic we should get rid of QAndroidStyle, QGtkStyle, QWindowsStyle, etc. That's not an argument against an implementation merely existing. You can use the Fusion style for your project, and I'll use the iOS style for mine. There's no reason we can't have the best of both worlds. Now on the technical issues, to use your own sentence against you, it's not as bad as you think. You don't need to install event handlers within the style and do frame by frame updating hacks. All the iOS widgets inherit from UIControl, where you can set the highlighted (when you touch down), selected, and enabled/disabled states of a control; no need to fake input events to do it. Control styling is also more flexible than it seems. You can in some cases retrieve images for the individual parts of a control. A lot of the standard graphics can also be replaced with custom images, and through that functionality you can use trickery to do things like draw a slider's track and knob separately. The controls also provide some degree of metrics information (like text margins), and you can use trickery to do things like draw the backgrounds for left, middle, and right sections separately for a UISegmentedControl in selected and unselected states. Or the divider. I could even give you a slider with two knobs if you wanted. I've already started writing code for this and have been pleased with the results so far. Also, I just have to respond to this: 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 The second part of your sentence answers the first. I don't see how that's a problem at all. That is essentially the same way any styling API works - each frame, you tell it to render. Any internal state it might update as part of that process is not your concern. I know this is not the case but HITheme could be using a NSSlider internally, for example, and you'd never know it. So, to summarize: As Morten said, The way to prove us wrong is of course to step up and implement (and maintain) such a style.. Therefore, I will implement and maintain QiOSStyle. Of course any help would be appreciated as well. Now, I want to stress this fact: I'm trying to support everyone's use cases, not exclude anyone at the expense of others. QStyle is used by both widgets AND QtQuick.Controls. All of these use cases are perfectly valid: widgets + custom style, widgets + native style, QML + custom style, QML + native style. So, the only thing left to say is that I hope the issue is not whether QiOSStyle is welcome in QtGui at all, but simply whether it can be technically achieved and whether there is someone to do the work. If it's the latter, then we're all set and can end the discussion, since I will do it. Otherwise, QiOSStyle will be on GitHub. I'd much prefer it to be upstreamed. PS - To everyone debating the merits of widgets vs QML in general: this thread is about the implementation of an iOS QStyle to draw native-looking controls for QWidgets AND QtQuick.Controls. Could you please continue those discussions in a different thread? -- Jake Petroules Chief Technology Officer Petroules Corporation · www.petroules.com Email: jake.petrou...@petroules.com___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt for iOS - iOSStyle
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
Re: [Development] Qt for iOS - iOSStyle
On Tue, Mar 12, 2013 at 07:56:33AM +, 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,,
Re: [Development] Qt for iOS - iOSStyle
I agree 100% with Jens. That is all. tor arne On 3/12/13 8:56 , Bache-Wiig Jens wrote: [snip] ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt for iOS - iOSStyle
I'm already working on some preliminary testing for QIosStyle. I don't know how long it'll be before I have something on Gerrit but it will come. -- Jake Petroules Chief Technology Officer Petroules Corporation · www.petroules.com Email: jake.petrou...@petroules.com On Mar 12, 2013, at 7:52 AM, Sorvig Morten morten.sor...@digia.com wrote: 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. Complexity, maintenance burden and lack of manpower are the main reasons against, yes. And I think Jens summed up the technical issues well. The way to prove us wrong is of course to step up and implement (and maintain) such a style. Morten ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Qt for iOS - iOSStyle
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. 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. 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. 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. :) -- Jake Petroules Chief Technology Officer Petroules Corporation · www.petroules.com Email: jake.petrou...@petroules.com___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt for iOS - iOSStyle
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. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt for iOS - iOSStyle
On Mon, Mar 11, 2013 at 08:37:19AM -0700, Thiago Macieira 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. The point is that the current alternative is far from perfect as well. I don't find it hard to accept that not everyone is happy to shift compile time effort to runtime effort, or is willing or even able to drop his established workflows and tools, even on mobile platforms. Combined with the insight that the old widgets don't cut it in the animated touch space and there's no resources to maintain two stacks one might have expected a single, fully compilable stack with optional script bindings on top as primary goal. Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt for iOS - iOSStyle
On Mon, Mar 11, 2013 at 08:37:19AM -0700, Thiago Macieira 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. 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. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- 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 smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt for iOS - iOSStyle
On segunda-feira, 11 de março de 2013 19.45.48, André Pönitz wrote: On Mon, Mar 11, 2013 at 08:37:19AM -0700, Thiago Macieira 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. The point is that the current alternative is far from perfect as well. Indeed, but the current solution is not an option either. QtWidgets will not get the full look and feel of iOS. It was not meant to do animations and the effects required by their LF. So we have no solution at this point. And I'd argue that QtWidgets will not ever be good enough, whereas the Qt Quick solution can be. Combined with the insight that the old widgets don't cut it in the animated touch space and there's no resources to maintain two stacks one might have expected a single, fully compilable stack with optional script bindings on top as primary goal. If that's possible, sure. But it's possibly even easier to write a single Qt Quick-based solution, with no C++ API. Given the lack of manpower, that's an alternative to consider. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt for iOS - iOSStyle
On segunda-feira, 11 de março de 2013 16.54.31, Rafael Roquetto 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. That will give you the right static look, but not the feel. In order to implement the right feel, with animations, shadows, etc., you need a lot more. If things glow, slide, bounce, it will be extremely hard to implement with QtWidgets. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt for iOS - iOSStyle
On Mon, Mar 11, 2013 at 01:40:18PM -0700, Thiago Macieira wrote: On segunda-feira, 11 de março de 2013 16.54.31, Rafael Roquetto 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. That will give you the right static look, but not the feel. In order to implement the right feel, with animations, shadows, etc., you need a lot more. If things glow, slide, bounce, it will be extremely hard to implement with QtWidgets. It is *harder* than with QML - but possible. And I don't think it is that hard. I am not saying that is easy, though. We used QtScroller (kineticscroller) for instance, to implement smooth list view animation. If you can render using the native API to an off-screen buffer, than it is doable. I would even risk to say that hard is not the proper adjective here, but instead laborious. To implement things like glowing, one can for instance implement an event handler inside the style that monitors mouse events and does the job of animating. Well at least it worked well for BlackBerry but I can't say anything about Mac since I don't know the API. If someone decides to give it a shot, though, I would be happy to help. Having said that, I agree QML components are the most sensible way to go. Just my $0.02 Rafael -- 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 smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt for iOS - iOSStyle
here is one other solution http://docs.appcelerator.com/titanium/latest/ javascript and native looking widgets under ios Raul On Mar 11, 2013, at 10:58 PM, Rafael Roquetto rafael.roque...@kdab.com wrote: On Mon, Mar 11, 2013 at 01:40:18PM -0700, Thiago Macieira wrote: On segunda-feira, 11 de março de 2013 16.54.31, Rafael Roquetto 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. That will give you the right static look, but not the feel. In order to implement the right feel, with animations, shadows, etc., you need a lot more. If things glow, slide, bounce, it will be extremely hard to implement with QtWidgets. It is *harder* than with QML - but possible. And I don't think it is that hard. I am not saying that is easy, though. We used QtScroller (kineticscroller) for instance, to implement smooth list view animation. If you can render using the native API to an off-screen buffer, than it is doable. I would even risk to say that hard is not the proper adjective here, but instead laborious. To implement things like glowing, one can for instance implement an event handler inside the style that monitors mouse events and does the job of animating. Well at least it worked well for BlackBerry but I can't say anything about Mac since I don't know the API. If someone decides to give it a shot, though, I would be happy to help. Having said that, I agree QML components are the most sensible way to go. Just my $0.02 Rafael -- 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 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt for iOS - iOSStyle
On Mon, Mar 11, 2013 at 01:38:28PM -0700, Thiago Macieira wrote: On segunda-feira, 11 de março de 2013 19.45.48, André Pönitz wrote: On Mon, Mar 11, 2013 at 08:37:19AM -0700, Thiago Macieira 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. The point is that the current alternative is far from perfect as well. Indeed, but the current solution is not an option either. QtWidgets will not get the full look and feel of iOS. It was not meant to do animations and the effects required by their LF. So we have no solution at this point. And I'd argue that QtWidgets will not ever be good enough, whereas the Qt Quick solution can be. Combined with the insight that the old widgets don't cut it in the animated touch space and there's no resources to maintain two stacks one might have expected a single, fully compilable stack with optional script bindings on top as primary goal. If that's possible, sure. Why shouldn't it be possible to have a clearly layered stack with proper interfaces? But it's possibly even easier to write a single Qt Quick-based solution, with no C++ API. Given the lack of manpower, that's an alternative to consider. I am not sure I understand what this alternative would consist of. A solution that pushes common activities that can be done at compile time to every user's run time is not an approach that scales well outside the Mobile App comfort zone the current incarnation of Qt Quick is addressing. It does not scale down to real embedded, and it does not scale up to the usual bunch of engineering applications Qt was serving well in the past. Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt for iOS - iOSStyle
On Mar 11, 2013, at 5:36 PM, Raul Metsma r...@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.macie...@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.roque...@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.petrou...@petroules.com___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt for iOS - iOSStyle
On segunda-feira, 11 de março de 2013 23.02.02, André Pönitz wrote: Why shouldn't it be possible to have a clearly layered stack with proper interfaces? Maybe possible is not the right point. The point is whether it is feasible with the time and manpower available. Defining a proper interface takes time. Not defining it saves time, therefore allows us to finish the higher-level API sooner. But it's possibly even easier to write a single Qt Quick-based solution, with no C++ API. Given the lack of manpower, that's an alternative to consider. I am not sure I understand what this alternative would consist of. A QML-only API. A solution that pushes common activities that can be done at compile time to every user's run time is not an approach that scales well outside the Mobile App comfort zone the current incarnation of Qt Quick is addressing. It does not scale down to real embedded, and it does not scale up to the usual bunch of engineering applications Qt was serving well in the past. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
