UXP to C++ Plugin Communication

#1

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!

1 Like
#2

@kerrishotts could you please take a look at this request? I’m wondering if Can I use `eval` or similar functions? can be a solution

#3

No, we’d need real communication, not a JS-in-JS interpreter.

1 Like
#4

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.

2 Likes
#5

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).

You can find a great discussion about security concerns which also affect this request at Run External Application from XD Plugin

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).

1 Like
#6

Pablo, totally understand your concern. This conversation is a bit confusing as we have two topics going on. I’ve created a new topic regarding making system calls, so we can just focus on C++ communication here.

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).

1 Like
#7

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.

4 Likes