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

Shawn Rutledge shawn.rutledge at digia.com
Wed Jan 16 19:34:20 CET 2013


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.

It's kindof like the question how do you identify the type of an object
in QML or JS?  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.

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




More information about the Development mailing list