Important: Please read the Qt Code of Conduct -

QMLViewer app or wrapper?

  • Hey guys

    I have been writing some QML applications for Symbian and I'm a bit confused by the differences of the 'application' and the 'wrapper' (in Qt-Creator).

    The wrapper seemed to make the most sense for me as I can distribute my application as a .sis. However, it appears they work differently. For example, the wrapper (selected through New Project -> Qt Quick Application) does not have the 'runtime' object. So I can't check orientation. I had to use a workaround involving QtMobility. I think there was more too.

    I was wondering why they don't offer the same features and if there's a plan for them to be the same? In the future, when QML apps are deployable through Ovi Store, will they use the QMLViewer application or require a wrapper through Qt Creator?

  • There is "another way": to achieve this.

    Both methods (qmlviewer and wrapper/own runtime) have pros and cons.
    Using the qmlviewer, you can write an pure QML app and don't need to worry about cross-compiling / toolchains / etc. IMO this is the perfect way for simple applications and games.

    With a wrapper, you can either simply use QDeclareviveView + setSource or instantiate and configure each part of the puzzle (e.g. QGraphicsView, QGraphicsScene, QDeclarativeEngine, etc). Although you need to know a little of C++ (and worry about building the binary), this method provides more flexibility, what can be useful in certain scenarios. I see this method mainly as the path for more complex applications, that have both C++ and QML code.

    I'm curious to see what will be the Ovi Store requirements for QML apps. IMHO both are important and if they don't allow the qmlviewer way, I hope they provide a transparent way of creating simple wrappers.

  • Yes, I have been using that method you link to as a workaround for runtime.orientation :).

    You can still get by using both C++ and QML code with the QMLViewer application though, right? By using QML plugins.
    This example shows that method:

    I was unable to get the plugin compile to create a .dll so I opted for including the plugin within the QMLviewer wrapper. However, having the plugin within your QMLViewer wrapper means you get no auto-complete on your plugin types (!!). This can get pretty ugly. Unless there's a solution?

    So is there anything that wouldn't be possible using the QMLViewer Application? If Nokia somehow make it installable with a shortcut for 'qmlviewer app.qml' in Application Menu, then perhaps QMLViewer wrappers would not be needed for Ovi Store?

  • [quote author="xsacha" date="1291255293"]Yes, I have been using that method you link to as a workaround for runtime.orientation :).

    You can still get by using both C++ and QML code with the QMLViewer application though, right? By using QML plugins.
    This example shows that method:

    Yes, you can! If you can install your plugins in the default plugins path or adjust the plugins search path, that's ok. I just don't know how to do it on Symbian (I've never tried) - can anyone help us on this?. On Maemo it's ok.

  • I think you have to have the plugin listed in qmldir. Does this not work?
    It mentions this in that link.

    where FileDialog is the name and plugins is the directory it is contained in.
    In qmldir:
    plugin FileDialog plugins

  • Moderators

    anselmolsm: I doubt that Ovi store will allow QMLviewer based programs to be uploaded. The reason is simple: It will break the security concept as the viewer will happily load C++ plugins that have full access to the system with all the capabilities of the QML viewer.

    Severly trimming down the capabilities available to the viewer is an option, too, but then the QML apps it can run will be pretty boring as they can not access any interesting information.

    Give Qt Creator 2.1 a try (RC is out!). We did improve the QML C++ wrapper quite a bit there.

  • What were the improvements in the wrapper for 2.1RC? I'm trying it now and it forced me to change QmlApplicationViewer::LockPortrait to QmlApplicationViewer::ScreenOrientationLockPortrait :P I haven't noticed anything else yet though. If you show me the new features I can use them :).

    Thanks for info on QMLViewer, Tobias. I guess wrapper is the way forward.
    Is there any way for the Qt-Creator to know about QML Type's I have registered in my main.cpp rather than a plugin.dll? As they are compiled with the wrapper, it seems there is no way of it knowing? Just a bit annoying that I have all these squiggly lines underneath my Type's.

  • Tobias, what you said regarding security and Ovi Store make sense. So, the wrapper is the way to go.

    I'm using Qt Creator for my daily tasks to check the new features (I left emacs for a while :-P). The QML C++ wrapper is nice and I liked the basic structure created for a new Qt Quick Application project.

  • When I asked a Troll about the recommended way the answer I got was: wrapper!

    I use my QMainWindow as a property for the qml context so I can get all the information I wouldn't have any other way. Then it is just a matter of creating Properties on QMainWindow like "isPortrait".

    @ui->view->rootContext()->setContextProperty("topWindow", this);@

    @Q_PROPERTY(bool isPortrait READ isPortrait NOTIFY isPortraitChanged)@

    Also, on a side note: I haven't tried but another way of getting the orientation of the device is using the qt mobility sensors.

    p.s. I don't know why but my qt cretor (2.1 beta) does not mind me using topWindow.isPortrait on the qml code.

  • BTW: I don't actually use the QML Application wrapper ...just created a regular application and added the QDeclarativeView...

Log in to reply