How to create and load UI plugins?

kshegunov

@IL
Hello,
It is possible, although it depends on what exactly you're trying to achieve. An UI file is just XML file, that will be converted by the user interface compiler (uic) to a C++ class. You can't directly export that from a library, but there are several other options. Here are few possibilities:

Put the UI form in your plugin, sublcass QDialog and initialize it with the generated Ui class, export your custom QDialog derived class. You can then use instances of that class in your main application (albeit, usually you create these instances in the plugin).
Load your UI file dynamically from the main application (without plugins at all).
Load your UI file dynamically OR use a generated Ui class, initialize a generic QDialog in the plugin, make the connections needed and then return the instance to the main application.

Note that when you put and export classes from a dynamic library you might need to think about binary compatibility.

Kind regards.

IL

@kshegunov
Hello and thanks for replying,
I want to tell you what I am trying to achieve because I kind of lost with all the details that you gave me.
I need the ability to dynamically load UI in addition to the main application UI’s that I have during running time and have the ability to access this UI, I also need that the dynamic load UI will be independent, meaning the plugin that contain the UI will have his own logic that is not depend on the main application code. I believe it required some kind of registration also. Now I able to:

Dynamically load UI using UiLoader like in this example, but this is not helping me.
Dynamically load and run plugins without UI using QPluginLoader but this is also not helping me.

I believe that the second option is the one that I need but QT creator doesn’t give you the option to create library plugin that contains UI, it only asking you about dynamic or static library, and I need it to be with UI.

Hope you still can help me with that.
Best regards,
IL

raven-worx

@IL said:

I believe that the second option is the one that I need but QT creator doesn’t give you the option to create library plugin that contains UI, it only asking you about dynamic or static library, and I need it to be with UI.

Simply create a Lib project in QtCreator.
Now the question is if you want a

shared library (linked dependency - program doesn't run without it), or
a Qt-plugin (discovered and loaded at runtime - program also runs without it)

Then simply add a UI file manually to your QtCreator project.
Right click on your project -> Add New -> Qt -> Qt Designer Form Class

Then you can either define a method on the library/plugin interface to create a instance of your UI class and return it.

Hint: if you declare this method as a slot or with Q_INVOKABLE you can call it even without knowing it's exact type (no need to include implementation headers)

kshegunov

@IL
Hello,
Plugins that contain GUI are in no way different from plugins that don't contain GUI. You create, set up and build your plugin the same way, whether it has GUI classes, or doesn't. This is the reason that QtCreator doesn't have anything specifically related to GUI plugins, they are simply a shared library that is loaded at runtime with the help of the QPluginLoader class. Any class, form or resource can reside in the shared library, just the same way it can reside in an application. So, to create Ui in a plugin, you follow all the same basic steps you take when you do it in your application project - create forms, create classes and so on. Take a look at this example, where plugins are created and used to extend the GUI part of an application. I hope this will help you to set your plugin up.

@raven-worx said:

Hint: if you declare this method as a slot or with Q_INVOKABLE you can call it even without knowing it's exact type (no need to include implementation headers)

You don't include implementation headers in any case. The application defines the acceptable/expected interfaces and the plugin creates the instances behind these abstract classes. I don't see how making a function invokable through the meta-object system helps you.

raven-worx

@kshegunov said:

You don't include implementation headers in any case. The application defines the acceptable/expected interfaces and the plugin creates the instances behind these abstract classes. I don't see how making a function invokable through the meta-object system helps you.

And how does this magic happen?
When we really talk about plugins which are "loosely coupled" with the executable how do you call custom defined methods of the interface when you don't tell the compiler the type of the created instance?
That's why i suggested the Q_INVOKABLE method, since you receive a QObject you can use QMetaObject::invokeMethod() on it...
For the plugin itself of course you do not need to include any headers, since they already come with Qt.

kshegunov

@raven-worx

When we really talk about plugins which are "loosely coupled" with the executable how do you call custom defined methods of the interface when you don't tell the compiler the type of the created instance?

Sorry, I don't understand what you mean.
Doesn't the knowledge about the exact instance type really defeat the purpose of a plugin? This'd mean that you'll have to know when compiling your application what plugins are potentially used ...

raven-worx

For example this is how Qt does it:
(using the - unfortunately undocumented - QFactoryLoader class)

look in predefined folders for plugins (imageformats, etc) -> see QCoreApplication::addLibraryPath()
then it tries to load the (predefined) plugin interface, which is already given by the folder where it is loaded from
the plugin interface is already linked into the Qt binaries (e.g. QImageIOPlugin, etc)

so when you write a custom plugin you can derive it from QGenericPlugin and implement it's create() method, which returns a QObject. This QObject is your UI instance for example. Or even a wrapper widget where you call convenience (invokable) methods, like i was talking about.

So the question is if plugins or a shared library is desired here.

Plugins also of course have the big advantage that you do not need to recompile the application when you add functionality via a plugin.

kshegunov

@raven-worx
Hello,
Maybe there is a misunderstanding. I fathomed IL's question to be that he wants to write plugins for his own program not for Qt. Then you define your interfaces and load your applications plugins with the QPluginLoader class. The QObject you get is the actual plugin class that you query for functionality by means of the interfaces you've defined in your application (as it is done in the plug & paint example I've linked). There is no QGenericPlugin plugin there. You just subclass QObject and through the desired interfaces you provide the instances you need. The QObject is just an entry point for your plugin and your application has no knowledge of the implementation specific details. Your plugin on the other hand has to include the interfaces it's implementing (which is normal) but not the other way around. See here the low-level API I'm talking about.

Kind regards.

raven-worx

yes, maybe this was a long shot from me.
But basically it's the same mechanism i was talking about.
Just Qt (QFactoryLoader) does most of the work under the hood automatically.

IL

@raven-worx
Hello and thanks,
Regarding your first comment/reply -
Quote:
Simply create a Lib project in QtCreator.
Now the question is if you want a

list itemshared library (linked dependency - program doesn't run without it), or
list itema Qt-plugin (discovered and loaded at runtime - program also runs without it)

Then simply add a UI file manually to your QtCreator project.
Right click on your project -> Add New -> Qt -> Qt Designer Form Class
End of Quote
The second option is what I need, and I already did that but after adding UI into the QT plugin, the project doesn't compiled any more, it complain about missing files, like ui_<project-name>.h and more.

What is the correct way to do that?

Best regards,
IL

raven-worx

try re-running qmake.
(Right click on project -> Run qmake)

IL

@raven-worx
same thing,
Running qmake is ok but build failed
it should at-least generate ui_project.h file but it doesnt do that.

kshegunov

@IL
Do you have your forms in your project, like this:

FORMS += myform.ui

I don't know what IDE you're using, for me QtCreator does this automatically, but it's possible it's different for you.

IL

@kshegunov
Yes I do have the file in my form project.
The thing is when I create new QT widgets application project, QtCreator creat the file.ui file and under the output folder build-...-Debug it create a ui_file.h which contains all the UI stuff
But when I create QtPlugin library project and add UI form, the ui_file doesn't create eventhough it adding include of it.
I am working with QT-5.5.0 and Qt Creator 3.4.2

Any idea?

kshegunov

@IL
When I go to the New file or project ... menu and then from the sidebar I select Library, I can choose from:

C++ library - this is what you actually want
QtQuick 1 Extension plugin - this is for QtQuick (not relevant to your case)
QtQuick 2 Extension plugin - this is for QtQuick 2 (not relevant to your case as well)
Qt Creator Plugin - unless you want to create plugins for QtCreator, this is not your project type.

I don't have a QtPlugin library project in my list.

raven-worx

@IL
seems like this is a bug in Qt5's qmake. That the build steps are not created correctly when TEMPLATE=lib
It works perfectly fine in Qt4.

IL

@kshegunov
Good,
Now if you go to New Project and select C++ Library
Under Type you will have three options:

shared library
statically linked library
Qt Plugin

I choose the third option, can you see that?

kshegunov

@IL
Aha, I see what you mean. Well, you won't be extending Qt, but your application, so choose Shared Library from the dropdown, not Qt Plugin.

IL

@kshegunov
Yap, Thanks, Thanks. :-)
Now It's generate all the required files, I also need to add QWidgets in Select Required Models.

Best Regards,
IL