how to communicate between plugin or app?

ChrisW67

@JianJian No, it does not. It does mean you need to organise your project a bit differently.

Here is a complete example: https://github.com/ChrisW67/qtforum-pluginplay
It works by creating a library containing the interfaces (abstract base classes) that is used by the application and the plugins. The application does not know of the specific plugin classes, only the interface classes. The application connects objects from the plugins using the interface. Neither plugin knows anything about the other or the application.

There is probably more than one (neater) way to achieve this.

JianJian

@ChrisW67 thanks for your reply, i use qmake, and the most important is that i use plugin because i really do not want to add library import in my pro file, so i can also compile my application without plugin lib/dll.
i have learned your code,it seems needs to add lib import in cmake file, i think it will have compile error if i have no plugin dll in my application.

ChrisW67

@JianJian said in how to communicate between plugin or app?:

I use qmake

All of this works with qmake. CMake and qmake just coordinate building the project and do not change the behaviour.

I have added qmake project files to the example. I also removed some stray files from the app directory.

i think it will have compile error if i have no plugin dll in my application.

No. The application requires the static library containing a skeleton interface. It does not require any of the actual dynamically loaded plugins to build. Try removing the src/plugins directory from the top-level PRO file and do a clean build.

SGaist

In addition to @ChrisW67, if memory serves well, the library that is common to the plugins and the application shall not be static as it will result in duplicated static meta objects being loaded and will cause trouble.

ChrisW67

@SGaist You are probably right. I did not see problems, but it was a trivial usage. No reason it cannot be a shared library.

JianJian

@ChrisW67 i have code like your way,and it still not work，this is my code: [https://github.com/xiaobingcaicai/qtpluginplay-demo],
1.uncheck the shadow build
2.compile the plugins sub-project
3.compile the app sub-project
show the error "undefined reference to `SenderInterface::staticMetaObject'"

ChrisW67

No need to build the sub-projects independently: just build the top level and it will recurse into the subdirectories.

PluginPlay project should build everything in order but:
- you are not building sub-project interfaces (commented out, and missing).
- you have omitted the CONFIG setting for ordered building (there are other ways to ensure the correct order but this is simplest)
Sub-project app depends on interfaces and so is unsatisfied.
Sub-project plugins depend on interfaces.

The interfaces library needs to be independent of both app and plugins: you have wedged it into plugins.

JianJian

@ChrisW67 i have also tested the way you said：The interfaces library needs to be independent of both app and plugins. still get same error.
i think the primary cause is the plugin is not imported in the pro file, so the signs symbol can not be reconized, but if i import the plugin in the pro,the app can not compile success if there is no pugin(.dll/.so) file

maybe i have also maked other mistakes 😂😂

ChrisW67

@JianJian Yes, look more closely at my example on GitHub.

The app does not need to link to, or include headers from, the plugin(s). The app only needs to know about the interface and the minimal link library it produces.

JianJian

@ChrisW67 the minimal link library you mean is the .a/.lib library file？

ChrisW67

Yes, the libinterfaces.a or equivalent depending on compiler.

I have modified the Git sources to make this library shared rather than static. So, on Linux you get:

.../src/interfaces/libinterfaces.so  # both the link and runtime library

on Windows you get (from memory):

.../src/interfaces/libinterfaces.a     # MinGW the link library
.../src/interfaces/libinterfaces.lib   # MSVC the link library
.../src/interfaces/libinterfaces.dll   # the runtime library

On my Linux box the resulting app executable is linked to these things at run time:

$ ls .
app  libbasicreceiver.so  libbasicsender.so  libinterfaces.so
$ ldd app  # the application with no direct linkage to a plugin
        linux-vdso.so.1 (0x00007fff1819c000)
        libinterfaces.so => ./libinterfaces.so (0x0000718c2b36f000)
        ...
$ ldd libbasicreceiver.so  # a plugin
        linux-vdso.so.1 (0x00007ffdc8fe8000)
        libinterfaces.so => ./libinterfaces.so (0x000070653e942000)
        ...