Question about plugin environment

django.Reinhard

Hi,

my app has grown, so that I'm thinking about separating it into several plugins. I have no experience creating/using plugins, so I'm a bit unsure about how to setup the project.

I guess, that common code, that is used by plugin and application must be located in a library. Does that library need to be a plugin, or can it be a static library?
What happens at linking?
Guess I have to link that library against app and plugin.
How to avoid duplicates?

I plan to use both static and dynamic loaded plugins. Did I understand that right, that both variants only differ by qmake tag CONFIG = plugin versus CONFIG = plugin static?

How to I tell qmake the build-order?
I.e. first the static library, than the plugins and finally the app?

I already started dividing app and I run into a strange problem.
I have a baseclass that is located in library like this:

class A
{
public:
  virtual void riseError(const QString& msg);
  virtual void riseError(const SystemError& err);
...
  };

in my app there's an extension to that class like this:

class B : public A
{
public:
  virtual void riseError(const SystemError& err);
...
  };

In my application I use both calls and those of class A result in a compile error "cannot convert 'QString' to 'const SystemError&'"

Is this a problem of separation into library and application, or what am I missing here?

SGaist

Hi,

Did you already check the Plug And Paint ?

mpergand

@django-Reinhard said in Question about plugin environment:

In my application I use both calls and those of class A result in a compile error "cannot convert 'QString' to 'const SystemError&'"
Is this a problem of separation into library and application, or what am I missing here?

You can't do that in C++:
https://stackoverflow.com/questions/27227189/overload-virtual-function-with-different-parameters-in-c

But i think you use virtual in a wrong way, from your exemple, I don't see any reason for this functions to be virtual. (it's just function overloading)

mpergand

@django-Reinhard said in Question about plugin environment:

my app has grown, so that I'm thinking about separating it into several plugins

You can also use sub projects ( .pri )
for example in the .pro, I do:

# MPQt Application
include( ../Qt5.12_Sources/QtApplication.pri )
# UIWidget
include( ../Qt5.12_Sources/UIWidget_v1.2.pri )

QtApplication is the main core classes that I use in all my projects
UIWidget is special widget classes that I use here:
https://forum.qt.io/topic/131769/how-to-change-the-background-of-qtableview-header/16

django.Reinhard

@SGaist said in Question about plugin environment:

Did you already check the Plug And Paint ?

Yes, that was my starting point. I read the recommended links too, but did not find an answer for my questions.

@mpergand said in Question about plugin environment:

@django-Reinhard said in Question about plugin environment:

In my application I use both calls and those of class A result in a compile error "cannot convert 'QString' to 'const SystemError&'"
Is this a problem of separation into library and application, or what am I missing here?

You can't do that in C++:
https://stackoverflow.com/questions/27227189/overload-virtual-function-with-different-parameters-in-c

Hm, can't find any explanation about why not.

But i think you use virtual in a wrong way, from your exemple, I don't see any reason for this functions to be virtual. (it's just function overloading)

May be my understanding is wrong. Afaik both functions of class A are called overloading, whereas class B overrides one of A's functions.

I reread Stroustrups reference manual and I could not find a rule, why my sample classes are not allowed. It says, that for overloading functions must differ in function signatures and for overriding function signature must be the same.
Afaik both is true for my sample classes.

@mpergand said in Question about plugin environment:

You can also use sub projects ( .pri )

Thank you! That's a good idea. Have to read more about it.
But in my case - I'm thinking about optional parts, which might be loaded at user request/runtime only.
Like in the given example: some brushes should be available out of the box and some brushes should be loaded for nerds or kinky users ;)

ok, back to my question:
I took the directory layout from plugandpaint example:

Project
   +--- app
   +--- lib
   +--- plugins
        +--- plugin A
        +--- plugin B

In projects pro file I used app.depends = lib plugins
as read from plugandpaint example. But then I wanted to code, that plugin B depends on lib, so I used B.depends = ../lib written in pro-file of plugins directory, but then I got errors from qmake, that lib clean could not be executed?

Therefore my question about how to declare dependencies.

django.Reinhard

@mpergand said in Question about plugin environment:

You can't do that in C++:

I found an interesting discussion at SO, which points out, that my code is valid but incomplete.

There are (theoretically) 2 options:

add using A:riseError; - but that leads to qtcreator crash
override both functions in class B

meanwhile my project has reached a size where qtcreator crashes quite often.

I stil have troubles getting the new project structure built.
Following the plugandpaint example my project does not build. Everything gets compiled, but the libraries and plugins are not linked - so lots of unresolved externals.

I have to confess, that I don't understand the qmake-hacks in plugandpaint example. I did not find any words in docs.
I add the pro-file of one plugin:

 TEMPLATE      = lib
 CONFIG       += plugin static
 QT           += widgets
 INCLUDEPATH  += ../../app
 HEADERS       = basictoolsplugin.h
 SOURCES       = basictoolsplugin.cpp
 TARGET        = $$qtLibraryTarget(pnp_basictools)
 DESTDIR       = ../../plugins

qtLibraryTarget is used, but no word about where it is defined.

So how could I solve it?