Hello, I am developing a C++ plugin using a third-party library (Qt). While developing I put the necessary DLLs into the photoshop.exe folder. But where must I put them when I install my plugin on the user's PC?
Are there some photoshop-only search paths? I do not want to register those DLLs on PATH environment variable because then they will be visible to every program and may lead to DLL-hell on the user's PC.
Is there any solution?
+1 from me too, where where where?
Maybe put them with the plugin but load the DLL specifically with LoadLibrary.
Thanks for your reply. Unfortunately, it is not practically possible with the Qt library.
I believe adobe suggests installing third party plugins along with the nessacary dll files into
C:\Program Files\Common Files\Adobe\Plug-Ins\CC
As an example adobe includes dll files with the camera raw install and another example is the gmic plugin for photoshop
I checked Camera Raw plugin and it looks like it explicitly linked with those dlls (loads them with LoadLibrary function) - I cannot find those dlls in dependency list.
But Qt links implicitly (at compile time). So I cannot point Qt where to search its dlls dynamically. And in this case, I can only put Qt dlls at one of photoshop's search paths to make them visible to it. And if photoshop does not use something like SetDllDirectory or AddDllDirectory I can only use one of the paths that are visible to every installed application (PATH environment, system, or windows folders) or use photoshop.exe path.
gmic 8bf plugin does not linked with Qt library. It only runs *.exe in the subfolder which is implicitly linked with Qt.
Did you try placing qt DDLs in either root of photoshop (where exe is) or next to your plugin in the plugins folder?
I tried placing Qt DLLs in Plugin's and Photoshop's folders. Works only Photoshop's root folder. So I assume Photoshop doesn't adds Plugins folder to search paths (by AddDllDirectory) before loading plugins.
I don't think he does explicitly.
When I made plugin system and my sub plugins used qt stuff placing Qt dlls inside root folder was enough.
There is however a path for Qt that you can add. Something like QApplication::addLibraryPath or something like that.
Perhaps adding it in your main could help it... however not sure how would he be able to call it without qt dll hmmm... Maybe have a look at the source on > https://code.woboq.org/qt6/ and see how they do it & implement it manually in your main? Perhaps it will be enough to make qt work.
Let me know how it goes as I also want to stuff Qt inside photoshop.
How are you using Qt so far? How do you deal with threads/notifications? Does it run in parallel to photoshop or only during a specific action widget pop-up?
Another solution is to do a nested plugin.
photoshopPluginA essentially will just load dll and add paths to search dir.
It will then load logicPluginA(which uses qt/etc) and then forward all requests to logicPluginA.
I know it's a "Bad" idea, as plugin-loads-plugin, but maybe it would work.
In that config, you could even specify a global location for Qt/other dlls, like server shared folder. So maybe its a good solution for pipeline needs...?
Thanks for your reply.
> When I made plugin system and my sub plugins used qt stuff placing Qt dlls inside root folder was enough.
I do not know what plugin system and its structure you talking about. There can be many different subtleties in loading.
> There is however a path for Qt that you can add.
No, it will not help, because it is up to WinAPI and loader (photoshop in this case) where to search DLLs.
> How are you using Qt so far? How do you deal with threads/notifications? Does it run in parallel to photoshop or only during a specific action widget pop-up?
I am working with photoshop actions, so I just create QApplication, run needed actions, and close the application, all in kPSDoIt selector call by Photoshop. Photoshop normally processes those actions reflecting all changes during my application life-cycle. Yes, there is also an option to create QApplication in a parallel thread. I tried it and it also works.
> Another solution is to do a nested plugin.
Yes, thanks, it may be the solution in this situation, but needs additional work and testing.