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

Nurmi J-P jpnurmi at digia.com
Thu Jan 17 11:42:22 CET 2013


> 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?

> 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.

--
J-P Nurmi




More information about the Development mailing list