On Wed, Jan 16, 2013 at 9:14 AM, Mohamed Fawzi <[email protected]> wrote: > > On 16 Jan 2013, at 17:37, Alan Alpert <[email protected]> > wrote: > >> On Wed, Jan 16, 2013 at 2:22 AM, Rutledge Shawn >> <[email protected]> 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 _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
