Plugin verification data mismatch

[schooner]

Hi

I have a library of custom widgets for designer originally written under Qt 4.8

I modified according to the docs for Qt5 and when I build them for a new install of Qt 5.2, they build without a single warning but are not loaded in Designer and About > Plugins shows the error in the title
without saying what the mis-match actually is

I am using
Q_OBJECT
Q_INTERFACES(QDesignerCustomWidgetCollectionInterf ace)
Q_PLUGIN_METADATA(IID "org.qt-project.Qt.QDesignerCustomWidgetCollectionInterfac e")
in the library class definition

and I am not exporting Q_PLUGIN_METADATA for each widget individually, as per the docs

I can build a widget individually via QtCreator and it will be recognised by Designer, but it is impractical to split the combined header into individual widget def files and repeat the process 30+ times, that is what libraries are for.

None of the topics I have searched on come up with a relevant answer, a lot say use the Q_PLUGIN_METADATA macro and do not use Q_EXPORT_PLUGIN2, and I am doing this.

This works perfectly with 4.8.2, so what exactly has changed in 5 and how do you get Designer to accept a library?

Thanks

[wysota]

Is there a space between "c" and "e" in the plugin metadata line?

[schooner]

Hi

No, thats just some strange forum cut and paste shit

[schooner]

Well I have managed to build the library, but I am far from happy with what the problem is.

I used QtCreator to create a library containing just 2 widgets and then edited the files by hand to add in all the other widgets.
The alternative of using QtCreator to make the whole library would have been painfull in the extreme, as you cannot import existing files and have to specify each class and it files individually.

I thought I had the problem nailed at one point, being how the domXml string was made up in the plugin. Then I found that both the old way and the way Creator did it both worked

The only difference I can narrow down is the way the .pro file is set out.
Both .pro files produced makefiles that ran without error and linked a library, but only the library based upon the Creator original produced a library which was recognised by Designer.
All the main headings etc are the same, the differences seem to be that the plugins are listed first, along with all the headers, even if they don't describe a Q_OBJECT that will require a moc file.

I now have a template which I can base any future widgets upon, so my immediate problem is over.

I am left with a niggling doubt that Creator is somehow signing the library.
This is worrying, because I hate Creator (and all other IDEs) and normally never use it.

Whatever, it is the usual retrograde, backwards incompatibility from Qt, as if changing all the include names and locations every version was not bad enough.

If I didn't need 5.2 for a project, I would stick with 4.8.2, which has never caused the problems this has.

[wysota]

All the main headings etc are the same, the differences seem to be that the plugins are listed first, along with all the headers, even if they don't describe a Q_OBJECT that will require a moc file.
Plugins? Did you mean header files?


I am left with a niggling doubt that Creator is somehow signing the library.
Creator is not signing the library. Creator is just a text editor, the compilation process is the same regardless if you use Creator or not.


This is worrying, because I hate Creator (and all other IDEs) and normally never use it.
So don't. Creator is not a problem here, you must have an error in your code. If you share the code maybe we can narrow down the problem.


Whatever, it is the usual retrograde, backwards incompatibility from Qt, as if changing all the include names and locations every version was not bad enough.
I have no idea what you mean here. What include names and what locations are changed in every version, e.g. what changed between Qt 5.2 and 5.3?


If I didn't need 5.2 for a project, I would stick with 4.8.2, which has never caused the problems this has.
So something is bad just because you don't know how to use it?

[schooner]

Plugins? Did you mean header files?

I just mentioned headers and plugins in the same sentence so of course I don't mean headers.

If you are not familiar with designer plugin library files, why comment



I have no idea what you mean here. What include names and what locations are changed in every version, e.g. what changed between Qt 5.2 and 5.3?

When exactly did you start using Qt? Of course I dont mean between 5.2 and 5.3.

Every single version increment breaks the code written for the previous one.
2 to 3, 3 to 4 was particulary bad and now in 4 to 5 a lot of headers in particular have changed name and locations, along with deprecated functions which are not fully replaced.

On top of that, the way the X server is addressed has changed, because now Qt 5 graphic apps will not run at all on icewm any more.


So something is bad just because you don't know how to use it?

So Qt is faultless because you are completely wedded to it?

[wysota]

I just mentioned headers and plugins in the same sentence so of course I don't mean headers.
Can you provide us with a line in the project file for the plugin that lists "plugins" you speak of?


If you are not familiar with designer plugin library files, why comment
It seems to me that you are not familiar with them considering the fact you cannot obtain the effect you want. But let's assume I am not familiar with designer plugin library files, could you then please enlighten me? I always thought a Designer plugin project file consisted of lines listing SOURCES, HEADERS, TARGET, TEMPLATE and CONFIG variables and the example plugin project in the reference manual also uses these variables. Did you list your plugins in any of the mentioned variables or was it some other variable?


When exactly did you start using Qt?
About 10 years ago, why do you ask?


Of course I dont mean between 5.2 and 5.3.
So why speak of changes between every version of Qt? You either get upgrades that replace one code with better code (thus the change) or you stick with the old version, old code and no improvements. The choice is yours.


Every single version increment breaks the code written for the previous one.
Well, it doesn't break mine.


2 to 3, 3 to 4 was particulary bad and now in 4 to 5 a lot of headers in particular have changed name and locations
The API change between Qt 3 and Qt4 was indeed a major one and it indeed broke backwards compatibility but reasons for that were well explained many times (e.g. here: http://doc.qt.digia.com/qq/qq13-apis.html). Qt5 is in 99% backwards compatible with Qt4 on the source code level. I understand that you currently struggle with the remaining 1% but that's no reason to start a flame war. File locations are least of your problems as the build system abstracts that. Indeed the plugin export macro changed between Qt4 and Qt5 as the concept of plugins was extended and keeping the original macro would produce faulty code. Changed macro requires you to make an explicit modification in your code so that you are aware of the architectural difference. If you keep the old macro, you'll get a message about it during compilation.


along with deprecated functions which are not fully replaced.
Qt is open-source, feel free to contribute replacements for deprecated functions you consider missing.


On top of that, the way the X server is addressed has changed, because now Qt 5 graphic apps will not run at all on icewm any more.
I'm sure you can write a QPA plugin that will work for you, whatever the problem with icewm is. Based on a quick search I just did it seems to me the "fault" of icewm rather than Qt. I understand that you might be an icewm user and you'd expect things to work on your system but with changes incorporated into Qt between Qt 4.8 and Qt 5.0 the framework switched from working on millions of devices to working on billions of devices.


So Qt is faultless because you are completely wedded to it?
No. But the plugin system works for many people, so it is not "broken", you are just having problems with it and most likely if you shared an example code we would probably have already found and eliminated the issue.