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

Nurmi J-P jpnurmi at digia.com
Mon Jan 21 13:40:01 CET 2013


> -----Original Message-----
> From: Alan Alpert [mailto:416365416c at gmail.com]
> Sent: 17. tammikuuta 2013 18:24
> To: Nurmi J-P
> Cc: development at qt-project.org
> Subject: Re: [Development] Proposal: expose the OS/platform in QML
> 
> > 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).

There's a caveat. The Command modifier on Mac equals the Control modifier on other platforms. While "Cmd+." should close dialogs on Mac, "Ctrl+." should not close them on other platforms. Otherwise the key handling would be, in this particular case, identical across platforms. Using the platform selector technique would mean either duplicating the key handling for each platform or introducing a hint whether each platform wants to handle that special case or not. Somehow that doesn't sound very convenient to me. This is just some dumb example that came to my mind, but my point is that the real life is full of these little special cases here and there, which is also why the QtWidgets codebase is not entirely free of those Q_OS macros. :)

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

We can provide a guideline, but in the end we should let the users decide which technique suits them better, case by case. 
 
--
J-P Nurmi




More information about the Development mailing list