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

[Alan Alpert]

On Thu, Jan 17, 2013 at 2:42 AM, Nurmi J-P <jpnurmi at digia.com> wrote:
>> 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.
>
> I had the impression that platform selectors would work nicely for implementing alternate UI layouts for different platforms and form factors. Imagine components that have the same UI layout, but slightly different behavior what comes to eg. internal focus or input handling. If you already know that your code is only going to be executed on "full desktop" like environments, is it really that inelegant and horrible to check if we're on Mac then handle "Cmd+." as a special case?

I'm not quite following this usecase. As I understand it, it *is*
inelegant and horrible to check if we're on Mac and then handle Cmd+
as a special case. The key handling is cross-platform, you should just
handle "Cmd+" properly and it will only be triggered on platforms with
that key (Mac).

Much of cross-platform functionality you can just implement in the
generic case and platforms will only trigger what they're capable of.
When that doesn't work is A) Different looks for different platforms
B) Using types/properties not available on all platforms. You need the
selectors for B (because the QML files won't parse without the
feature) and you'd prefer selectors for A.

>
>> 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.
>
> They are not necessarily competing, but more like supplementary features.
>

Unfortunately they are competing, in the minds of users for which
should be used in a given situation. To prevent that, we'd need to
clearly define a separation in intended usecases: Where would you use
runtime platform detection over selectors?

--
Alan Alpert