How to distribute custom plugins in cross platform environments
-
I have written a plugin as a an option extension for my application, now I'm looking for a way to distribute it. Is there a standard way? How do other people do it? For windows I think it's not a big issue, just distribute a zip package with the plugin and the user can unpack it in the plugins dir of my application. For Linux it's a bit more complicate, the application is installed in the
/usr/local/bin, the plugin is a shared library so it gets installed inusr/local/lib64, is that the correct approach?Would be nice if someone could share some experience on this topic.
-
I have written a plugin as a an option extension for my application, now I'm looking for a way to distribute it. Is there a standard way? How do other people do it? For windows I think it's not a big issue, just distribute a zip package with the plugin and the user can unpack it in the plugins dir of my application. For Linux it's a bit more complicate, the application is installed in the
/usr/local/bin, the plugin is a shared library so it gets installed inusr/local/lib64, is that the correct approach?Would be nice if someone could share some experience on this topic.
@dporobic
what kind of plugin and what Linux distro?
Basically i would say create a deb/rpm package (at least) and set the dependency packages.If its a plugin extending Qt i would say install it directly to the Qt installation folder - otherwise the user has to worry about adding the plugin import path himself.
For example -
@raven-worx it's extending my own application, ksnip. Currently it's being installed here
/usr/lib/x86_64-linux-gnu/libksnip-plugin-ocr.sobut looking at the provided link, I should probably try to change it to something like/usr/lib/x86_64-linux-gnu/ksnip/plugins/libksnip-plugin-ocr.soYes, finding the plugins after installation is an issue. I first thought about setting env vars when installing but that doesn't seem to work for Linux. How does Qt know where its plugins are located?
-
Hi,
They are in a known folder folder following a specific structure.
It's explained in the plugins documentation.
For your application, how are you currently doing ?
-
In my application you can currently choose a directory where for plugins should be searched (checking the directory and its child directories, one level). I had in mind defining a default search path, like for Windows
QCoreApplication::applicationDirPath()/../pluginsand additionally supporting an environment variable, likeKSNIP_PLUGINS. First check env var, when empty, take default search path, when nothing found, well then the user has to input where he installed it.My ideas are currently failing for Linux as I cannot set the env var when installing the deb or rpm package and I cannot determine the default install path, could be
/usr/local/lib,/usr/lib/x86_64-linux-gnu/or something else.What's even worse, when you install the the package it doesn't say where it's installed so the user would need to look via
findfor it, which is not a solution for the average user. -
In my application you can currently choose a directory where for plugins should be searched (checking the directory and its child directories, one level). I had in mind defining a default search path, like for Windows
QCoreApplication::applicationDirPath()/../pluginsand additionally supporting an environment variable, likeKSNIP_PLUGINS. First check env var, when empty, take default search path, when nothing found, well then the user has to input where he installed it.My ideas are currently failing for Linux as I cannot set the env var when installing the deb or rpm package and I cannot determine the default install path, could be
/usr/local/lib,/usr/lib/x86_64-linux-gnu/or something else.What's even worse, when you install the the package it doesn't say where it's installed so the user would need to look via
findfor it, which is not a solution for the average user.@dporobic said in How to distribute custom plugins in cross platform environments:
In my application you can currently choose a directory where for plugins should be searched
And do you want to keep it like this?
Why should user care about this location? -
@dporobic said in How to distribute custom plugins in cross platform environments:
In my application you can currently choose a directory where for plugins should be searched
And do you want to keep it like this?
Why should user care about this location?@jsulm said in How to distribute custom plugins in cross platform environments:
And do you want to keep it like this?
Why should user care about this location?I want to keep that functionality that the user needs to start the check for plugins instead of on startup always checking if plugins are there. It's an extensions (the plugin) that most of the users won't need, but if you need it, you can download the plugin, tell the application where it is and then use it. This check is a one time thing, the found locations are stored in settings and on startup loaded.
I would prefer the user not to care about the location, to be able to automatically suggest to the user where to search (which I'm currently not able, see posts above). When the location cannot be found automatically (which is currently the case on Linux) then the users should be able to tell the application where it can be found.
-
@jsulm said in How to distribute custom plugins in cross platform environments:
And do you want to keep it like this?
Why should user care about this location?I want to keep that functionality that the user needs to start the check for plugins instead of on startup always checking if plugins are there. It's an extensions (the plugin) that most of the users won't need, but if you need it, you can download the plugin, tell the application where it is and then use it. This check is a one time thing, the found locations are stored in settings and on startup loaded.
I would prefer the user not to care about the location, to be able to automatically suggest to the user where to search (which I'm currently not able, see posts above). When the location cannot be found automatically (which is currently the case on Linux) then the users should be able to tell the application where it can be found.
@dporobic said in How to distribute custom plugins in cross platform environments:
you can download the plugin, tell the application where it is and then use it
In this case I would not package these plug-ins as rpm/deb packages.
A zip archive would be enough and user can then decide where to put the plug-ins. -
@dporobic said in How to distribute custom plugins in cross platform environments:
you can download the plugin, tell the application where it is and then use it
In this case I would not package these plug-ins as rpm/deb packages.
A zip archive would be enough and user can then decide where to put the plug-ins.@jsulm said in How to distribute custom plugins in cross platform environments:
In this case I would not package these plug-ins as rpm/deb packages.
A zip archive would be enough and user can then decide where to put the plug-ins.Problem is that it has a dependency, it relays on Tessarect that is installed with it. For windows I will package it in a zip as you said but on Linux it should be installed so the dependency can be resolved. Or is there a way to package it together with the dependency, like AppImage for libs?
