[Development] Qt5 missing features

lars.knoll at nokia.com lars.knoll at nokia.com
Thu Apr 12 09:15:44 CEST 2012


On 4/12/12 6:05 AM, "ext Alex Wilson" <alex.wilson at nokia.com> wrote:

>On Wednesday, April 11, 2012 07:25:41 pm ext BogDan wrote:
>> the problem with QML desktop components is that
>> not all controls are touch friendly (e.g. lists, editbox, etc.), even
>>they
>> have Android look the feel is not the right one. As I said, I believe
>>is a
>> waste of time to have 3 completely different ways to draw QML components
>> (desktop, symbian and meego) + one for classic widges.
>=snip=
>> so you'll end up with two QML components implementation, one
>> for pointer devices (desktop, N900, etc.) and one for touch devices (N9,
>> etc.)
>
>I really like this idea -- PointerComponents and TouchComponents, and
>when you 
>import them, you get the appropriate look and feel for the runtime
>platform, 
>without having separate QML files for each one -- just one QML file for
>your 
>touch UI ("mobile"), and one for pointer UI ("desktop").

Just that this doesn't take into account how things are evolving on the HW
front. I believe you'll start seeing touch screens on 'desktop' platforms
appear rather soon now, and if you look at Apple and Microsoft, you can
see that they are preparing their OSes for that.

So we might need components that can deal with both in some way and maybe
detect pointer vs touch at runtime.

Cheers,
Lars

>
>But currently the different QML components "implementations" for each
>platform 
>have completely different paradigms and ways of organising things... it's
>more 
>than just a simple "oh there are some widgets different" -- the entire
>API is 
>differently designed. So harmonising all the touch platforms and all the
>pointer platforms into those two groups under a standard banner for each
>would 
>be difficult, but necessary, I think, if we want QML components to be a
>serious 
>cross-platform UI offering to compete with our own QWidgets.
>
>It could also be the case that some platforms really have unique and
>specialised aspects (like e.g. some menubar stuff on OSX maybe), and
>these 
>should get special treatment, maybe in their own import just for apps
>that 
>don't mind writing some more platform-specific code. Of course this
>discussion 
>would be much simpler if QML had some equivalent to #ifdef that doesn't
>involve massive multi-file code duplication...
>
>-Alex
>_______________________________________________
>Development mailing list
>Development at qt-project.org
>http://lists.qt-project.org/mailman/listinfo/development




More information about the Development mailing list