[Development] Qt5 missing features

[BogDan]

> From: "lars.knoll at nokia.com" <lars.knoll at nokia.com>

> To: alex.wilson at nokia.com; development at qt-project.org
> Cc: 
> Sent: Thursday, April 12, 2012 10:15 AM
> Subject: Re: [Development] Qt5 missing features
> 
> 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


Don't forget about devices with completely different screen sizes, you can't
expect a full-feature desktop application to fit into a phone (no matter how 
smart is the phone),  it seems Android found a good solution [1],[2], so 
developers  who want to have a completely cross platform solution can do it 
with just a little effort.

BogDan.

[1] http://android-developers.blogspot.com/2011/02/android-30-fragments-api.html
[2] http://developer.android.com/guide/topics/fundamentals/fragments.html