Since the previous post, the InDesign team has let us know that Hybrid Plugins are coming soon, however at the moment, no C++ API access or UXP to C++ SDK communication methods are planned.
UXP to C++ communication in some form is crucial to enable to developers to have a Web Frontend (JS/CSS/HTML) with the ability to run C++ APIs on the backend to fill in any limitations in the UXP API.
Here is an example of how this is achieved in Photoshop for reference:
A. C++ API Functions embedded in a UXP Hybrid Plugin
This method a UXP plugin can ship all the regular UXP plugin code as well as binaries for C++ Hybrid Plugin functions enabling 1 plugin to do it all.
B. Communication methods between a UXP C++ API Functions in a UXP Hybrid Plugin
This method allows a UXP plugin to communicate with a traditional C++ SDK plugin with the host app which is ideal for already existing C++ plugins and certain workflows where Hybrid Plugins don’t make sense.
Photoshop Example of UXP to C++ SDK communication:
Thank you for reviewing this. Including one or both of these capabilities in UXP will make UXP adoption a far more feasible option for many developers.
As far as I’m concerned, it’s a prerequisite for porting to UXP. As it exists in CEP and Photoshop, I don’t understand why it couldn’t be done quickly in indesign.
Hey InDesign team, we followed Adobe’s push to migrate from CEP to UXP, but now we can’t fully distribute our plugins, and support requests are stacking up. Without a direct UXP-to-C++ solution (like Photoshop has), we just can’t handle certain tasks. We need this capability ASAP to keep our customers supported and our plugins viable. Thank you
While this would be a good thing, don’t forget that InDesign’s scripting object model is dynamic, and can be extended via C++ plug-ins. Plug-in scripting objects/properties/methods are merged into the InDesign DOM when the plug-in is loaded.
These extensions to the model are all available in UXP scripting–we (SPI) use this in our Silicon Connector C++ plug-in. I was actually a little surprised that this works, given the overall roughness of the UXP roll-out.
This has always been the best way–in my opinion–to communicate with C++ plug-ins in InDesign. Photoshop, for example, does not have a dynamic DOM, and so could not use this approach.
Edit: I think it’s possible that the InDesign team took you a little too literally when you asked about C++ plug-in access, and didn’t consider using scriptable plug-ins as a solution.
I agree with Ole when it comes to communicating with existing C++ plug-ins from UXP. The ability for C++ plug-ins to expose a scripting surface is really the ideal way to do this, and should be sufficient. That addresses item B in Justin’s original post.
Item A does seem like a legitimate need. It would be really nice to enable UXP hybrid plug-ins to access the C++ DOM for those tasks where processing speed makes a difference. While the scripting API should be sufficient for most needs, if you’re doing a hybrid plug-in you’ve already gone beyond what the scripting API can offer, so this seems like an important feature.
Hi @justin2taylor,
I am Ramanjulu from Adobe InDesign team.
We understand your concern, thanks for bringing this ask to our notice.
We haven’t planned for it yet. Please give us some time to understand the technical challenges and limitations with respect to InDesign.
We will get back to you once we have a plan ready.
Out of 1000+ C++ APIs, if there is a list of APIs that you are specifically looking at, please let us know.
For the beginning, could you describe how we should get started with hybrid plugins.
Are there any documents similar to Justin’s link? Not so much, I looked at Changelog which is still at 20.0 and does not mention “hybrid”.
Or should we look into the SDK? I just downloaded the latest 20.1 SDK and while “hybrid” is used in several places, nothing stood out related to UXP. Programming guide, porting guide.
Any separate SDK? Whitepaper? Anything?
Justin’s PS doc mentions only one “suite” for passing messages around. It also describes related setup similar to what I remember from Illustrator. A very different level of abstraction from what we have with InDesign plug-ins, and much older. Higher level than facades that usually are already too high.
As you mention 1000+ C++ APIs, this sounds like you were planning a walled garden version of the SDK, emulating the antique plug-in architecture of the other products. Wrap opaque handles up in suites. It shows that UXP architecture was created to fit Photoshop. Not good, we already had a “Highlevel API” a decade ago, and it was abandoned because nobody would use it if you also have the real thing.
That’s great that a lot of this behavior can be replicated manually in the ID DOM, like you said this is rarely the case in other Adobe apps, however I still think that unity across UXP implementations is essential.
Adobe has generally always supported communication channels between various APIs ( BridgeTalk / Vulcan / PlugPlug / CSInterface / ExecuteScript ), while you can create your own communication streams around these it makes the most sense for Adobe to provide this on their end for developers.
And to recap on the initial post, Hybrid Plugins were always on the team’s road map, my initial post was just requesting they come out sooner so people can fully migrate their tools. C++ binary access / CLI access is just 1 of the facets, the other big one is app API access.
Thank you for the update we look forward to hearing more!
I think both routes (A & B) would be fantastic to have, but even if we had 1 to start, that could pave the way for more UXP adoption and migration sooner.
Hybrid Plugin access in InDesign was casually mentioned during the last Adobe Office Hours so it’s currently in Beta, not technically released, so it won’t show up in the changelogs yet.