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

[Joseph Crowell]

On 01/17/2013 04:34 AM, Shawn Rutledge 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.

But that is what J-P is trying to do: Create a pixel perfect replica for 
the OS.

>
> 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.
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development