-
Notifications
You must be signed in to change notification settings - Fork 43
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider using Qt's plugin framework instead of ignition's #11
Comments
Original comment by Michael Grey (Bitbucket: mxgrey, GitHub: mxgrey). From the documentation of QPluginLoader:
Note that in Qt terminology, a "plugin" is equivalent to a "shared library".
Note the use of the word "unloaded" here. It seems that "unloaded" means explicitly calling the From the description of the
This means that the burden of keeping track of whether a shared library is still in use falls on us. We can load a shared library, spawn a QWidget from it, and throw away its I think if we care about being able to safely unload libraries that are no longer in use, we'll want to stick with the (@chapulina Note that this is different than what I had said to you earlier. I thought the destructor of |
Original comment by Michael Grey (Bitbucket: mxgrey, GitHub: mxgrey). Interestingly, the post you linked to is using a conceptually identical library management model to what we have in This is making me think we would be best off sticking to the Somewhere in
Then the user-code would look like this:
Later on, once the self-aware plugin infrastructure is ready, we can tweak the implementation of the
The user wouldn't have to make any change to their code, and as soon as they recompile against the latest version of For the record, I'm kind of upset that I can't think of a way to use one macro instead of two, but we kind of need one of those macros to be called inside of the user's namespaces while the other macro needs to be called outside of those namespaces, so I can't think of a way to merge them into one macro. |
Original comment by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina). pull request #65 has a temporary solution |
Original comment by Nate Koenig (Bitbucket: Nathan Koenig). Is this still relevant now that we are moving to qtquick? |
Original comment by Nate Koenig (Bitbucket: Nathan Koenig).
|
Original comment by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina). With QtQuick, our interfaces are not As of now, the main window object is keeping ownership of all plugin objects and releasing the shared pointer when the plugin is closed. So I think the original "temporary" solution from pull request #65 is still working. However, I'd like to keep this issue here at least until all pending features have been added to ign-common's plugin framework - it is my understanding that there are more pull requests on the way and I'm not sure how they will affect ign-gui. |
Original comment by Nate Koenig (Bitbucket: Nathan Koenig). The ignition-plugin framework is now stable, or at least no additional features are planned. |
Original comment by Nate Koenig (Bitbucket: Nathan Koenig). sounds good. |
Ignition plugin has been working well for us, so closing. |
Original report (archived issue) by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).
Qt provides its own plugin framework. It might be a good idea to use that instead of Ignition Common's, since in theory it is especially tailored for Qt.
There is some urgency sorting this out since there is a pull request landing into ign-common's default branch soon which will break compatibility with Ignition GUI.
Some things to be figured out:
Does Qt provide the same features as Ignition, such as:
How much effort would it be to support the ign-gui case with ign-common's new plugin loader? Is it worth the trouble?
@mxgrey
The text was updated successfully, but these errors were encountered: