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

[Alan Alpert]

On Wed, Jan 16, 2013 at 9:14 AM, Mohamed Fawzi <Fawzi.Mohamed at digia.com> wrote:
>
> On 16 Jan 2013, at 17:37, Alan Alpert <416365416c at gmail.com>
>  wrote:
>
>> 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?
>
> Well getting information on the current system is generally available on all
> platforms, and can be useful, for example as way to cope with something
> not handled by selectors.
> I can understand your fear of it being misused, and the problem is real,
> still I think that it is more an education problem (making clear that selectors
> are the superior alternative, and explain why).
> If we have a good selector method I believe people will use it.

We haven't actually defined what selectors handle yet, but I got the
impression that all of these details will be handled by selectors. If
they are all handled by selectors then the 'education problem' becomes
one of telling users: "Never use this API, everything it does can be
done better using selectors". In that scenario, I think it really is
better to not have the runtime exposure at all.

Perhaps we should reconvene this thread after we agree on what
selectors cover? Or would that be too late? There's a clear need for
better cross-platform and cross-device support in QML (for Qt 5.1
ideally), but I don't think that means we should rush in two competing
implementations. Better to examine the use cases and tailor the two
APIs so that they holistically support the existing needs.

--
Alan Alpert