Several tools of mine rely upon 2-way communication between Scripting and C++ plugins.
This is currently accomplished in After Effects with:
AEGP_ExecuteScript() (C++ > Scripting)
ExternalObject() DLLs like PlugPlug (for Scripting > C++)
From what I’ve heard, this isn’t currently available with UXP. Communication between the two environments, even in a basic eval sense I think is extremely important for a lot of us when we’ll be converting our CEP tools to UXP. Thanks!
I’d like to add my 5 cents to this since all of my extensions are using external libraries and systemCall as well.
Not having those in the new framework will babsically kill lots of great tools.
While I agree with the feature request, I’ll again (like in a few previous feature requests) say that I think that it would be unwise to implement something like system level interaction, which this – in one way or another – requires – without a good permission system (since it’s very easy to install plugins with the plugin manager and potential malware could damage the opinion about plugins in XD a lot).
For basic communication (although I do understand that that isn’t as easy to use in C++), you can always use the WebSocket API as long as your application is already running (which would mean communication is possible – opening that app if it isn’t running is then a whole different issue and handled in the request I’ve linked to above).
Regarding C++ plugin access, WebSockets are not going to fill all the use cases here. WebSockets work great for communication with external apps (I’ve used this before), but communication between C++ plugins and UXP Panels within Adobe apps really needs to be more direct. For instance, I have some C++ plugins which will run ExtendScript functions on their own that are only possible in ExtendScript. This wouldn’t work with WebSockets, as a specific panel would also have to be open to receive a message, run the command, and return the result. The inverse is also true will calling C++ commands from UXP (ExtendScript in the past).
UXP was built to make it easy for host apps to expose their APIs into the plugin’s context. We use abstraction layers like N-API (and some internal equivalents) to accomplish this. There’s no reason that I can see that a product that supports a C/C++ layer wouldn’t be able to provide a similar sort of interop with the JavaScript layer.
Exactly how we expose that to third parties is a question mark. Adobe XD doesn’t have this concept, and so it wasn’t something we built in to UXP version 1. Only point products like Photoshop and After Effects have this concept, and we’re only now in the early stages of thinking about how the API should look, and how such interactions between C/C++ and JS can occur.
In short, this feature is going to be host dependent – that is, the point product must have the infrastructure in place to support C/C++ plugins. Adobe XD does not have plans to have a C/C++ plugin layer at this time, but that doesn’t preclude UXP from providing support in other point products.
To give an update on this topic for anyone reading 5 years later, this is somewhat possible at the moment, via C++ Hybrid Plugins.
Hybrid Plugins can let you run C++ functions from UXP and get results. Also there are some examples of accessing Photoshop C++ APIs as well via Hybrid Plugins:
How this will look in the rest of the Adobe apps has yet to be seen.
We have a boilerplate ready-to-go with a Hybrid Plugin setup for anyone interested: