Important: Please read the Qt Code of Conduct -

Platform specific part of QML-file?

  • I want a qml-object to only show up if my application is compiled for mac os. How do I do that?

  • 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:
    class PlatformDetails:public QObject
    Q_PROPERTY (bool isMac READ isMac)
    PlatformDetails(QObject*parent =0);
    bool isMac();

    PlatformDetails::PlatformDetails(QObject* parent):

    bool PlatformDetails::isMac()
    #ifdef Q_OS_MAC
    return true;
    return false;

    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:
    @#if defined(Q_OS_SYMBIAN)
    int platformId = 0;
    #elif defined(Q_WS_MAEMO_5)
    int platformId = 1;
    #elif defined(QT_SIMULATOR)
    int platformId = 2;
    // desktop probably
    int platformId = 3;

    viewer.rootContext()->setContextProperty("platform",  platformId);
    return app.exec();@

    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):
    @function resolvePlatform() {
    switch(platform) {
    case 0:
    return setSymbian
    case 1:
    return setMaemo
    case 2:
    return setSimulator
    return setDesktop

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

    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, 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...
    f3.source = ./symbian/plat = qml
    f3.source = ./win/plat = qml

    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

  • Just a quick update to the thread: It seems that now you can check the platform directly in your QML code:

    @ if (Qt.platform.os === "linux" || Qt.platform.os === "windows" || Qt.platform.os === "osx" || Qt.platform.os === "unix") {

    This doesn't seem to be documented anywhere else though :S (so not sure if this can change, without notice).

    Got the reference from:

  • "QQmlFileSelector": is intended to handle this situation.

  • [quote author="qt_sur" date="1411406074"]Just a quick update to the thread: It seems that now you can check the platform directly in your QML code:

    @ if (Qt.platform.os === "linux" || Qt.platform.os === "windows" || Qt.platform.os === "osx" || Qt.platform.os === "unix") {

    This doesn't seem to be documented anywhere else though :S (so not sure if this can change, without notice).


    That functionality is documented as part of the "QML global Qt object":

    I wouldn't worry about it disappearing.

  • My solution.
    width: Qt.platform.os == "Android" ? Screen.width : 480
    height: Qt.platform.os == "Android" ? Screen.height : 640

Log in to reply