> From: "[email protected]" <[email protected]> > To: [email protected]; [email protected] > 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" <[email protected]> > 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 _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
