[Solved]My custom widget will not show in Designer

ealione

As I said the plugin was indeed located under 'plugins>designer', but the designer that comes with QtStudio could not find it. Yet if I open the designer located in the 'bin' directory it seems that it can. So one actually has to copy the plugin under the plugins directory located in the TOOLS folder.

Chris Kawa

bq. so I am not sure with what compiler was my Qt version made with.

You can determine the compiler of Qt itself by inspecting the name of the package e.g. qt-opensource-windows-x86-msvc2013_opengl-5.4.0 will be Qt 5.4.0 compiled with 32bit MSVC 12.0 included in Visual Studio 2013 with the desktop OpenGL support.

Each such package contains a Qt library and built with it tools like assistant, designer or linguist. The plugins of this designer need to be built with the Qt package they are part of and the designer looks for them in the <Qt location>/<Qt version>/plugins/designer.

The installable Qt packages also contain some additional tools e.g. a compiler (in case of MinGW) and the Qt Creator(the IDE). Qt Creator is an app build with some Qt version, not necessarily the same as the Qt version of the package. It has its own set of Qt dlls bundled with it and the built-in designer looks for its plugins in <Qt location>/Tools/QtCreator/bin/plugins/designer.

To have a plugin work with the package designer and the Qt Creator designer you need to deploy the plugin into both of these directories.

Note that if the version of the Qt in the package is different than the version of Qt used to build Qt Creator you will not be able to use the same plugin file. For Qt Creator you need to build the plugin with the version it was built with. To find out which is it open Qt Creator and go to Help -> About Qt Creator. There will be a label saying "Based on <Qt version and compiler here>".

bq. the designer that comes with QtStudio could not find it

What's QtStudio? Do you mean the Qt Creator?

ealione

Yeah I meant Qt Creator no idea how I came up with that name. Ok I think its clear now, I'll have to build Designer with my own compiler, in order for my plugin to work.

Thanks Chris.

ealione

There is another problem occurring now though. After doing what you described I have my analogclock plugin shown normally under Designer, and I also copied the analogclock.h file together with the other includes in Qt.

I get unresolved externals:

@mainwindow.obj:-1: error: LNK2019: unresolved external symbol "public: __thiscall AnalogClock::AnalogClock(class QWidget *)" (??0AnalogClock@@QAE@PAVQWidget@@@Z) referenced in function "public: void __thiscall Ui_MainWindow::setupUi(class QMainWindow *)" (?setupUi@Ui_MainWindow@@QAEXPAVQMainWindow@@@Z)@

Yet the actual analogclock if run as a normal app and not a plugin runs fine, and my header and source files for the plugin are based on the Docs.

Chris Kawa

bq. and I also copied the analogclock.h file together with the other includes in Qt.

I'm not so sure this is a good idea. It works but polluting Qt directory seems fishy.

bq. I get unresolved externals

The plugin (.dll or .so depending on your OS) is loaded dynamically by the designer.
To use your custom type in your own app you need to link to the library (.lib or .a depending on your compiler) of the plugin i.e. add this to your .pro file:
@
LIBS += -Lpath/to/your/plugin/build/dir -lyourpluginname
@
You will also need to distribute the plugin library (.dll or .so) with your app.

bq. Yet the actual analogclock if run as a normal app and not a plugin runs fine

Yes because it compiles the class code into your executable while when you use a plugin it needs to link to an external library that contains the class code.

ealione

I did felt a little bit of guilt while copying the header file in Qt, but what else is there to do, my widget needs the header file, and if in the future I create an actually useful widget that I want to use all the time wouldn't it be better than having to copy that header for each project?

Chris Kawa

I actually never create my own plugins because to me they are more hassle than they're worth, so take my opinion with a grain of salt, but here it is:

I would treat the plugin as any other shared 3rd party library you use (because they're basically just that). Create a directory for it where you keep your libs with "include", "lib" and "bin" sub-directories and put your .h, .lib(.a), and .dll(.so) files there.
When you create multiple projects using them just add the proper LIBS and INCLUDEPATH info into the project's .pro file.

ealione

Makes sense actually. I just did this as a small exercise to see how it would be possible to add another widget to the designer, but I believe that your suggestion is quite sensible. Besides I would have to distribute those plugins so having the properly organised is the smart thing to do.

Going back to the plugin though my link problem persists even though I added

@LIBS += -LC:/Users/PC/Downloads/plugin/analogclockplugin.lib@

as well as other variations such as

@LIBS += -LC:\Users\PC\Downloads\plugin\analogclockplugin.lib@

@LIBS += -LC:\Users\PC\Downloads\plugin -lanalogclockplugin@

@LIBS += C:\Users\PC\Downloads\plugin\analogclockplugin.lib@

This is on windows and the actual plugin is named "analogclockplugin.lib" and the dll "analogclockplugin.dll"

Chris Kawa

Should be:
@
LIBS += -LC:/Users/PC/Downloads/plugin -lanalogclockplugin
@
Note the -l (lowercase L) and omission of the file extension (.lib),
-L specifies directory, -l library name.

If you want to use backslashes you need to double them e.g.
@
LIBS += -LC:\Users\PC\Downloads\plugin -lanalogclockplugin
@
otherwise they are threated as escape sequences \U, \P, \D and \p which are invalid

ealione

Yes I forgot to mention it, this was the first thing I tried since you suggested it in the first place, yet i still get the unresolved external

@mainwindow.obj:-1: error: LNK2019: unresolved external symbol "public: __thiscall IconEditor::IconEditor(class QWidget *)" (??0IconEditor@@QAE@PAVQWidget@@@Z) referenced in function "public: void __thiscall Ui_MainWindow::setupUi(class QMainWindow *)" (?setupUi@Ui_MainWindow@@QAEXPAVQMainWindow@@@Z)@

No idea why, this is not the first time I'm using an external library. I successfully did it with many database drivers in the past.

Chris Kawa

After you edit .pro be sure to re-run qmake (from the Build menu) so it will pick up the changes.

ealione

There must be something on a deeper level here that I am getting wrong.

The original plugin was created in this way:

A .cpp and .h file named analogclock.cpp and analogclock.h respectively.

I then did another project, as describer by the tutorial, comprised by analogclockplugin.h and analogclockplugin.cpp.

In the includeFile() function for the plugin I added analogclock.h.

After that when trying to run a test project containing this plugin, and after modifying my pro file including the created lib, and having copied analogclock.h in Qt's include directory I get the link error mentioned.

I then tried removing analogclock.h from there and instead putting

@HEADERS += mainwindow.h
analogclock.h@

in my pro file (after having of curse copied the header file in my project directory) I get an unresolved external for every function inside the header file.

Trying to add

@INCLUDEPATH += "C:/Users/PC/Downloads/plugin/inc"@

results in the header not being found, even though from the little I know it should work.

Am I forgetting to include something, or is it indeed the case that I am doing the whole process wrong?

EDIT

After reading "this":https://qt-project.org/forums/viewthread/31454 I see that I must have (for the same widget) a designer plugin and also a library, something that was not mentioned in the docs. Is this indeed the case? and if yes how do those two differ (in the pro file settings I mean)?

Chris Kawa

Ugh.. there's an important distinction that you missed and I have followed along by mistake. Sorry for that.

In your app using the custom widget you should not link to the plugin lib. It's for the designer only.
In your app you should either include the analogclock.cpp in the project or create a separate project that builds a lib of the class and link to that, not the plugin lib.

Basically a class library and a plugin library that displays that class in the designer are two different projects, so you're linking against the wrong thing. the lib you have exposes the plugin class, not your custom widget class.

ealione

I knew I'd confuse you sooner or later, it's a personal skill of mine. I hope whoever reads this will be able to easily understand the solution through my multitude of posts.

WolfgangGriech

@ealione said in [Solved]My custom widget will not show in Designer:

After reading "this":https://qt-project.org/forums/viewthread/31454 I see that I must have (for the same widget) a designer plugin and also a library, something that was not mentioned in the docs. Is this indeed the case? and if yes how do those two differ (in the pro file settings I mean)?

I'm well aware of that this thread is already 10 years old, but anyway guys like myself are still reading this until today. So to clarify the statements above, it is NOT true that you'll need 2 different libraries for the designer plugin supplied to QtCreator / QtWidgetDesigner, and the widget library used for linking the contained widgets to your own code. We're happily using the very same library for both purposes, since Qt4.7 or even earlier, until the latest and greatest Qt6.8. Of course there has to be the appropriate interface information supplied for those 2 purposes, but all this can reside in 1 library only.

SGaist

@WolfgangGriech hi,

From memory, the suggestion to have a plug-in and separate library is to keep the dependencies down to a minimum because otherwise you would pull the designer library into your application.