[Development] Proposal: expose the OS/platform in QML

[Alan Alpert]

On Wed, Jan 16, 2013 at 2:22 AM, Rutledge Shawn
<Shawn.Rutledge at digia.com> 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