On Thu, Jan 10, 2013 at 4:16 AM, Attila Csipa <q...@csipa.in.rs> wrote: > On 10-Jan-13 04:25, Alan Alpert wrote: >> So I'll try to replace "cross-platform" now with "cross-device". > \> but I still prefer run-time). Android has the same problem, I have a >> lot of apps on my Nexus 7 which either literally or metaphorically do >> not work on that device. There are also apps that just have an ugly >> black border thanks to the auto-compatibility layer. As a convenience >> GUI toolkit, I think Qt should have some way to help application >> developers with this problem. I'm just focused on QML because I'm >> always focused on QML :) . > > Have it clear if the selection is features, platform or devices, because > if you have a vague mix, the results will be weird. "BB10" means very > little in this context - I know you will adjust margins, but you will > also have to leave out WebView elements, QtMultimediaKit, etc, and > that's an adaptation that's not reusable if it all gets stuck under a > "BB10" directory/tag (for example iOS might also not have QtWebkit). To > me a "BB10" tag sounds more like "cascades" because that's one thing > that has 1:1 relation with the platform. Devices tags are also a weird > proposition (so do we now get a "2013 13" Macbook Air" tag? or is this > mobile-only? do we mash all 10 variants of SGS3 into one?).
Sadly, this is not clear. My initial thought was platforms because that's the distinction you need in order to vary platform component sets. But plasma's approach is form-factor based, so you can vary design across different form factors (different devices) on the same platform. So unless anyone has a better idea, my thought was to make the implementation agnostic to this so that we can let the tags evolve somewhat. > The Qt > heritage so far was, to maximize portability level, to "test for > features" - something sadly currenly NOT possible in an easy way in QML. The Qt heritage so far was desktop, where cross-device compatibility meant "make sure it'll still work in 640x480 resolution". Desktop devices are all very similar, even touch-screen computers always have a mouse and keyboard as well (consequently, their touch interface was ignored for the longest time). Add to this that full-screen applications are not the norm, and then you use resizeable layouts more and don't optimize for a particular exact window size. A specific mobile device selects your exact window size, your selection of user inputs, and a different UI framework (one that can't be hidden away like QtWidgets did). The Qt heritage so far solved the problems of its era. Now there are new problems. > The other problem with "BB10" or "Android" style tags is "which > version"? BB10 might put in features from upstream Qt later, but how > would you know if your selected QML was meant for BB10 10.0 or 10.1, ICS > or JB Android (back to the imports story)? There are and will be cases > where the same binary needs to run on different Qt setups. Device > firmware upgrade cycles are not guaranteed, and while some platforms > might do ministro/smartinstaller-style upgrades, it's still not a > complete solution - users probably won't be happy people triggering tens > of megs of Qt downloads every now and then just because an extra > property has been introduced. I still think "then don't use it" is a > poor argument as it means "You're stuck with the first major Qt release > for that platform forever". This isn't about selecting versions of imports. You always write for the current version of the platform, and when the platform updates you update your app if you need new functionality. This is for the case where the current versions of the platforms across all the devices are known, but you're deploying to multiple devices and/or platforms. -- Alan Alpert _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
