[Development] Qt5 missing features
bog_dan_ro at yahoo.com
Thu Apr 12 10:35:46 CEST 2012
> From: "lars.knoll at nokia.com" <lars.knoll at nokia.com>
> To: alex.wilson at nokia.com; development at qt-project.org
> 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>
>> 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
>>> 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
>>> (desktop, symbian and meego) + one for classic widges.
>>> so you'll end up with two QML components implementation, one
>>> for pointer devices (desktop, N900, etc.) and one for touch devices
>> I really like this idea -- PointerComponents and TouchComponents, and
>> when you
>> import them, you get the appropriate look and feel for the runtime
>> without having separate QML files for each one -- just one QML file for
>> 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'
> 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.
>> But currently the different QML components "implementations" for
>> have completely different paradigms and ways of organising things...
>> than just a simple "oh there are some widgets different" -- the
>> 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
>> be difficult, but necessary, I think, if we want QML components to be a
>> 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
>> should get special treatment, maybe in their own import just for apps
>> don't mind writing some more platform-specific code. Of course this
>> would be much simpler if QML had some equivalent to #ifdef that doesn't
>> involve massive multi-file code duplication...
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 ,, so
developers who want to have a completely cross platform solution can do it
with just a little effort.
More information about the Development