Qt Widget Library vs. Qt Plugin advice

[Pl45m4]

I've finished one of my larger projects and want to make a library out of it.
(or Qt plugin, I'm not sure)

I know the basics about C++ libraries, static and dynamic linking, made simple non-Qt C++ libraries and know what a Qt Plugin in general is, but I'm still not sure what the best approach would be to implement my idea.

My "project" as it is right now, is a standard Qt Widget CMake project with a framework-like collection of custom widgets.
For me (and any other potential user) to be able to include these widgets in other Qt projects, I want to provide an interface (library or plugin) so you don't need to actually copy or move the code to your own project (also not sure if I want to share the source code anyway).
The idea is that the user can "include" or load (plugin) every single widget by itself... So not a "public library" header (#include <MyWidgetLib>), which interfaces everything the library has to offer, but each of my widgets independently, like #include <QMyWidgetA> and #include <QMyWidgetB>, if that makes sense?!

What I'm not sure about:

1. Plain library or Qt Plugin(s) in general? What's more fitting this case?

   • and: one for everything? Or one lib/plugin for each widget? (some of them depend on others)

2. How to link/use Qt? As I don't what to get in trouble with any license issues (with obligation to LGPL)

   • currently my project links Qt dynamically as I'm an open source user and installed Qt DLLs via online installer.

3. If my library is a static lib, how to link the Qt dependencies to it? They have to be statically linked as well, right?!
   ( which might be a license issue then)

   • or can a static lib depend on dynamically linked 3rd party code?
     (weird question, I guess not, since when linking statically, the symbols are included in the binary executable... and you can't add more to it dynamically, right?!)

4. I used the QtCreator library wizard and it created a mylib_global.h file...
   What is it all about? When I plan to use multiple public library interfaces/headers (one of each widget, as mentioned above) instead of one single public header for the whole lib, how to deal with it? Do I need multiple _global.h files as well? The SharedLib Qt guide mentions it, but how to deal with it if I leave the "usual route"?

5. I maybe want to add a Qt Designer Plugin for each widget later... Does this have any influence on the decisions I have to make now?

I've read this, this as well as this, but I'm still not clear what I need (and need to do).

As always, any help, hints and clarification appreciated :)

Thanks :)

[Pl45m4]

Update:

Discovered the DocumentViewer Example, which is a multi-project "solution" and includes an app as well as a shared library interface for various Qt Plugins (different "viewers", like pdfviewer).

It makes some things clearer, but is all that really needed if I just want to provide my own QWidget - based class(es) via a shared library?
It feels like so much "overhead"?!
Does every QObject-based class in a library have to be interfaced by a "Qt Plugin"?

I've checked multiple, random GitHub repos with custom-made Qt Widgets, but all of them only provide the source code to include the classes in your project or even act as an inspiration only to copy parts of the code.
There's nothing like its own widget library to build and to link your program against, to be able to "use" the widgets...
Which is exactly what I thought of and what I'm trying to do...

Maybe I'm asking the wrong questions and I already know the answers myself, but it feels like I'm missing something (how to deal with my widgets, etc.)...

Still open for any input :)

[SGaist]

Hi,

If you are targeting Qt applications that you want to extend, then yes, build plugins based on the Qt stack.
The drawback of libraries in this case is that you have to link them to your application every time you add something new while with a plugin approach, you simply drop the new plugin in a folder of your application.
You don't need to have each and every object exported through a plugin. It's only the bits that you want to interface that should explicitly come from it.

[Pl45m4]

Hi, thanks for your feedback.

@SGaist said in Qt Widget Library vs. Qt Plugin advice:

If you are targeting Qt applications that you want to extend

Yes, but

The drawback of libraries in this case is that you have to link them to your application every time you add something new while with a plugin approach, you simply drop the new plugin in a folder of your application.

I don't really need that drop-in functionality. Either you choose to include / link my "widget collection" or you don't.
It's fine not being able to replace components in a "hot plug" manner.
I just thought that you still need a QtPlugin for any QWidget or QObject you want to integrate into your Qt app and a plain C++ library won't work there (for some mysterious MOC / QObject reason) :D
Good to know that I was wrong :)

For my understanding:
QtPlugins are for components you want to (un-)load at runtime through the shared library interface, right?
QtPlugins and QtDesigner plugins are limited to the software versions with which they were built, correct?
(Designer Plugin built with QtCreator 12.0.1 won't work in Designer of QtCreator 14 and QtPlugin built with Qt 6.5 won't work on Qt 6.7 projects?!)

[aha_1980]

Afaik, unloading of plugins is not recommended/supported

[SGaist]

For user created plugins... That's a good question.
I know plugins for Qt itself (the ones listed under Qt extensions are checked for Qt version mismatch but I currently don't know whether it's also the case for the low level API such as the one you'd be using for your application.

That said, if your goal is to provide a set of widgets for other to use in their application (such as the widgets module), then there's no need for plugins.

[Pl45m4]

@SGaist @aha_1980

Yeah, I thought of "low level" plugins anyway, as I don't want to extend Qt ifself, but a user application with my widget library.

@SGaist said in Qt Widget Library vs. Qt Plugin advice:

That said, if your goal is to provide a set of widgets for other to use in their application (such as the widgets module), then there's no need for plugins.

Ok, I'll try a plain shared library and see how it goes :)

Thank you both of you.