Search code examples
qtqmlqtquick2qt5.5

Embed QML Dialog inside QDialog window at runtime


I've never used QML before and I don't know if the following is even possible at all.

I'm currently porting a C++ Qt Application to Qt 5.5 with existing code and lot of UI files. This application later loads a lot of C++ plugin dll at runtime. Now every plugin should have its own configuration dialog; although none of these plugins currently have a Qt dependency.

I'm currently thinking about extending the interface with something like:

class CPlugin {
    public:
        virtual std::string const& getQmlDescription() const;
        virtual std::string const& getQmlFilePath() const;
};

So every plugin can return a set of QML data on how it wishes it's configuration dialog to look like.

When this plugin should get configured by the user, this application displays an empty QDialog and asks the plugin "give me your qml config data"; which is then rendered and executed inside the empty QDialog.

Can this QML data in terms of a string buffer or a file path to the QML data be interpreted and rendered into a empty QDialog at runtime?

Bottom line:

  1. Can QML be handled like this at runtime?
  2. Can I embed a QML Dialog description inside a traditional QDialog window or does these two types not mix?
  3. Is this even remotely a good idea or should I do a hell lot differently? :)

Solution

  • There's no reason to use a QDialog. You could do it, but a QDialog is rendered using the raster paint engine, and you'd be using the CPU to composite that with the OpenGL frame buffer that Qt Quick renders into. It'd be a bad premature pessimization.

    In your scenario, the QML from the plugin would be passed to QQuickView. You will also find that the plugins will need access to the QML engine to set up the context objects to interface C++ to QML, and to register their objects. You can use a global engine instance, and pass it to plugins. Or, to isolate them, use a dedicated engine that only services these plugins.

    Qt Quick is flexible in that you are not forced to have the Qt Quick items from the plugins in separate windows. You can set them up in a flickable front-end for mobile devices, dockable front-end for desktop applications, etc. The visual items from the plugins can be instantiated any way you wish - multiple times, inside of other items, etc.

    So, it might be a better idea for the plugins to register their visual Item types with the engine, and let your application decide how to use these types, via a Loader, instead of simply passing you raw QML to deal with.