On Wed, Jan 16, 2013 at 2:22 AM, Rutledge Shawn <[email protected]> wrote: > On 16 Jan 2013, at 8:21 AM, Bache-Wiig Jens wrote: > >> True. It is exactly what we would use to implement the platform selector. >> But it can also be more powerful than that because it makes it possible to >> implement your own platform selectors if you disagree with whatever >> mechanism we come up with. (i.e you can create a loader that takes dpi, os, >> orientation and resolution into account)
It's still not clear to me how this is intended to co-exist with the platform selector thread. If we implement the static selector approach for QML like discussed in the other thread, then you can use that in loaders (because you can have it apply automatically to the source URL passed to the Loader). So you would not need to expose the OS/platform to QML at all in order to implement these selectors. How would OS, DPI etc. be used in QML then? >> >> I wonder how useful it is to know the platform plugin though. I.e I don't >> really care if I am on wayland or x11 or when writing QML. If I did, I would >> probably we writing a C++ extension. >> >> What I primarily care about is if I am on "mac", "windows", "linux", >> "android" or "iOS". This is information I would use quite often and only >> exposing that would be a good start. > > Where should we put that information? Orientation, resolution etc. will be > in Screen. I wonder if this gives us another reason to rename the Window > module to something more inclusive like System or Device. Then it will make > sense to expose all the device-specific stuff in the same module. I want to > rename it anyway to avoid having the present situation that you import > QtQuick.Window in order to create a Window (and get some other stuff that > comes along for the ride). I can't find the current docs, but the mobility APIs already exposed a wealth of system information in the SystemInfo plugin: http://doc.qt.digia.com/qtmobility/qml-systeminfo.html . The right place for all this more device general stuff is there, we can just bring that back in Qt 5 (if it isn't already). I really think that SystemInfo is a much better place for this than Screen, which is supposed to encapsulate the screen you're currently running on (not the whole device!). It also has a lot of other useful device information. >> Second, it would be useful to know if I am on a "phone", "tablet" or >> "desktop" platform. ( can already guess by the resolution but perhaps it >> would be convenient to abstract it a bit. > > That's a short-term classification, and anyway other types of devices are > coming. In a couple of years it will probably seem quite anachronistic to > make a distinction between just those three. What's a Galaxy Note, a phone > or a tablet? It's both. The trend is that even laptops are getting > touchscreens and touch UIs, and desktop machines without touch are being > minimized. What's more important is the physical size of the screen, how > many physical pixels are in a virtual pixel (although I still think that's a > dubious concept), whether you have multiple touch support, and if so, how > many fingers. Finding out about the touch support needs to be in this > System/Device/whatever module too (probably as a property of the Screen). > Likewise I plan to add the orientation from the accelerometer soon. > > OTOH we need to encourage app authors to write as generic code as possible to > make them as portable as possible. We can expose more information, but using > it to customize the UI should really be discouraged. Otherwise it could turn > out like the web javascript nightmare, having to customize for different > browsers, especially before HTML 5. So from that perspective maybe exposing > too much is wrong, because it will enable this scenario. We need to encourage generic code with powerful generic components, but we also need to enable specific code. There is the usecase of someone trying to get their app "out" as much as possible (cross-platform is a plus) and there's the usecase of someone writing for a specific device or device family (where Qt is still a benefit *if* it has cross-device support). This is another advantage of the separate SystemInfo plugin. The functionality is available, but it's not there by default so you have to actually need it before you start using it. -- Alan Alpert _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
