As far as I know, there is no API for that (yet). You can create a QObject in C++ that exposes the platform and insert that in your QML context.

Ew.. I expected that. The desktop-components are too fresh yet.

Can I find an example for the method you describe anywhere?

Not that I know of, but it would be quite simple I think:

And then you simply create an instance an insert it into your QML context. Of course, you can make the class a bit more useful by returning an enum that can represent all the platforms instead of a simple boolean for mac, but you get the idea.

Could there be some compile-time switch?

After all the QML code is wrapped into a c++ application and at the moment of compilation you do know the platform. Then a #define could include different Settings.qml for each platform. That is what I am thinking about for my own project (need some fine-tuning for Symbian, MeeGo, Android).

It would be cool to see a complete example from somebody though.

Maybe you can do that in the .pro file. At least you can check for Win, Mac and Unix.

I had a similar challenge to have some variation just for Maemo (and not for Symbian). My project is pure QML, c++ part is just a thin wrapper generated by Qt Creator wizard and I wanted the platform dependence be isolated to as small piece of c++ as possible.

What I ended up with was using C macros in main.cpp to define a qml context-wide property the following way:

Then in your qml you’ve got a platform property that can be used when doing property binding or inside a function the following way (my code returns a different set of settings for the different platform):

Certainly this run-time platform dependency switch still means that you need to include all your files to the project regardless of whether they make sense for a platform – I didn’t find a way to use .pro syntax for replacing e.g. Settings.qml at build time.

That also means that unless you are ready to mess with Loader your qmls should compile on all the platforms you are interested in. For example, if you want to target Maemo5 as well, you need to use “import Qt 4.7”, not “import QtQuick 1.0”.

P.S.
The code above is proof of concept for now. In your real app, you will certainly use proper constants, not just numbers.

@artem I wonder if it works but you may try DEPLOYMENTFOLDERS or DEPLOYMENT with platform scope values to include qml or whatever files that is only needed for the target platform.

I tried playing with DEPLOYMENTFOLDERS and failed. QML files are gathered using poorly documented combo of folder_01.source, folder_01.target and DEPLOYMENTFOLDERS

Whatever I was doing I failed to put qmls from two different source folders into the same path inside a binary – they always tend to have a path specific component. Further investigation showed that this logic comes from generated qmlapplicationviewer.pri, but messing with it was too much for me.

hmm, not sure what’s not exactly working for you but platform directive + DEPLOYMENTFOLDERS seems to work for me.

something like…

You’ll have qml/plat/ folder in target with files depending on the platform.

Maybe DEPLOYMENT is more flexible.

Hmm, I tried the similar code and it was resulting in two subfolders in the binary. If I remember correctly, I was getting something like: – qml/symbian/plat – qml/win/plat – qml/common (I had some common files as well)

That may be fine depending on what you want, but I wanted to put the files from both /win/plat and /symbian/plat to the same directory so that I could just replace Settings.qml and maybe some layout files.

Maybe this behavior is platform-specific. I tried on Mac OS X