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

[Alan Alpert]

On Wed, Jan 16, 2013 at 10:34 AM, Shawn Rutledge
<shawn.rutledge at digia.com> wrote:
> On Wed, Jan 16, 2013 at 08:37:27AM -0800, Alan Alpert wrote:
>> 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.
>
> I didn't mean the Screen object would have irrelevant stuff; my point
> is that there should be a specific import for the system-level stuff, and
> Screen and Window could probably be part of that same module because
> they aren't 100% portable (although they are mostly portable).  As
> it is, Screen is in the Window module.  But if you can get Screen
> you already can have enough information to optimize the UI for
> tablet/phone/desktop use cases (provided that the Screen object becomes
> complete enough, which it currently isn't); e.g. if the screen is over
> 5 inches then maybe it should have a tablet-optimized layout rather than
> phone-optimized, and if it doesn't have touch then you know there will
> probably be a mouse instead.  Unless you are trying to make a pixel-perfect
> replica that looks like it was made with native widgets, you shouldn't
> need the OS, windowing system, device name etc.

I agree the Screen object is a good place for information about the
screen. But there's no problem with having the windowing system
specific stuff in a Window import, and the non-windowing system stuff
in a Platform import (both of which should be "mostly portable").

The main thing you need other than Screen info is input method info.
It's not just that "phone" is a small screen and "desktop" is a large
screen. People assume "phone" means capacitive touchscreen and
"desktop" means keyboard and mouse (that's not always true, and it
would be better to separate out hardware input from hardware output).
So to property optimize your UI you need more information than even a
complete Screen object gives you.

> It's kindof like the question how do you identify the type of an object
> in QML or JS?

instanceof support in QML is on the todo list (still only gets done
when there's time to do it ;) ).

> One common answer is don't try, because the question you should
> probably be asking instead is, does the object have the properties I need?
> The fewer assumptions the code makes, the easier it is to port to different
> component sets and QtQuick versions.  It's the same with trying to tailor
> a UI specifically for some specific device that's only going to be sold for
> one year and used for two; you can bet that code will have a short life,
> and waste your time later if the app is worth porting to the next device.
> Personally I don't like rewriting things over and over again.

There is not currently a holy grail pattern for flexible UI design
across all devices (which really complicates the issue of what
functionality that hypothetical pattern needs). Once we've found that
pattern we can add whatever it takes to support "Write once. Deploy
Everywhere" again. Maybe what we need is to write a hypothetical QML
mockup of what a truly cross-platform, non-trivial application looks
like?

> The SystemInfo plugin has a bit more than "everyone" needs, but
> I agree the minority-use-case stuff could go in there.

The SystemInfo plugin has more than you need for pure UI
considerations. I'd agree that anything necessary for writing a
flexible UI, like screen info, should go somewhere more accessible.

>  But then it
> needs to be a Qt essential module so that app developers can depend on it.
> Some features will never work on every platform (brightness and contrast
> etc.), only on some.  Others just need attention to make them work everywhere
> that they can.  It seems like a mixed bag, and the docs don't make clear
> what you can depend on and what you can't.  "Mobility" is also a misnomer
> on a desktop machine.  If you want to write a QML app or component set
> that still runs everywhere Qt runs in 5 years, I doubt you want to be using
> that module in its current form.

Of course it needs to change, and the general idea was that all the
"Mobility" APIs would join Qt as essentials or addons where
appropriate. The only snag is that almost all the mobility developers
then left development for unrelated reasons, so I think they mostly
became addons.

--
Alan Alpert