InDesign plugin development C++ SDK Vs UXP

[Chamari_Silva]

We have few complex C++ plugins for InDesign built over many years. Now we are thinking of migrating these plugins to UXP.
Can we do everything we do in a plugin developed with C++ SDK, in a UXP plugin?
How do we achieve data persistentency?
Can we develop a Scriptable Plugin with UXP?

[Rahul_Rastogi · Accepted solution]

Hi @Chamari_Silva ,

Not everything can be achieved with UXP. Some of the things which can only be done by C++ Plugin -

Persistence - If you are using Persistence to save data at frame level or with Hidden Text Model. Then this cannot be done with UXP.

Alternative Solution- Use InDesign Tagging and save your data with XML tagging. This can be done through scripting.

Custom Tools - cannot be done with UXP 

Adornments - Adornments cannot be added with UXP. 

Custom Doc File Handler to override standard menus - File->Save, SaveAs etc can be achieved through UXP.

Custom Data Links - cannot be done through UXP.

There are multiple things that cannot be achieved through UXP so you need to be sure whether all your requirements can be fulfilled with UXP.

Also, C++ Plugin is much more faster reacting to events, observers, selection and changes. Incase you have complex business logic then C++ is the way to go.

Refer the post -

https://community.adobe.com/t5/indesign-discussions/adobe-indesign-c-plugin-or-uxp-which-is-faster/m....

- Rahul Rastogi

Adobe InDesign SDK Custom Plugin Architect

[Manan Joshi]

To add, UXP is still under development so things might not work as they should and also things may change. My suggestion would be first seperate out your C++ plugin functionality into different modules which are segregatted along the lines of what can be done only via C++ and what can be done with other technologies like UXP and then do the migration of these modules one by one, while creating a communication layer between these modules

-Manan

[Chamari_Silva]

Thank you so much @Rahul_Rastogi and @Manan Joshi.

Is there a documentation/ samples awailable for UXP where I can get an idea of what is possible with UXP and what's not. 

I've had a look at the UXP API reference (developer.adobe.com/indesign/uxp/reference/uxp-api/). Is everything included in there?
Also our plugins should be criptable to work with InDesign Server and that is one of the key requirements. Can we make scriptable plugins with UXP?

[Manan Joshi]

InDesign Server does support UXP scripting

https://github.com/AdobeDocs/uxp-indesign/blob/main/src/pages/scripts/tutorials/ids-object-model/ind...

-Manan

[Chamari_Silva]

Thank you @Manan Joshi.

Can we add custom objects, methods, properties, to the obeject model as we do in C++ plugins?

[Dirk Becker · Accepted solution]

With the introduction of CEP Adobe has weakened the concept of "plug-in" – it formerly meant what we now characterize as "C++ plug-in" comparable in most regards to what Adobe developers can do themselves, while it since CEP also includes "plugin" wrapped up scripts.

UXP plugins are closer to CEP plugins than to C++ plugins. Where CEP uses a reworked web browser in a separate process, UXP has its own subset of a severely stripped down (or half implemented) HTML+CSS renderer, directly living in the main process. Where CEP would send messages to ExtendScript to access the DOM, UXP is directly wired to the same scripting DOM. It also has more modern JavaScript features than ExtendScript which has not seen a language update in a decade. Throw in some features borrowed from node.js, wrapped up in a security model similar to web browsers.

Towards InDesign itself, UXP is still scripting. A plugin is a zip archive of html+js+image files. If you need a notification, you may be lucky and find it also in UXP, the same way that it was available in ExtendScript. One difference - notifications are enqueued somewhere and handled in async UXP, while main execution continues on (e.g. discards the event object). Not sure whether this was solved with 19.2 .

> Can we do everything we do in a plugin developed with C++ SDK, in a UXP plugin?

Depends on what "we do" means. UXP is scripting. You can't extend features that are extensible in the SDK - add to the preferences dialog. Implement an own tool in the toolbar, with tracker, snapped. Implement an own page item with extra wobbly border, or add to existing ones. Write an own preflight service, text adornment. Add owned items to text, or add an own strand. Write your own import or export format integerated into the export subystem. Tap into observers, responders, text filters, menu filters, selection handling. Run your own selection.

> How do we achieve data persistentency?

You modify script labels. Forget about persistent interfaces, own properties added to IDML or ICML. Much easier than handling data conversion, ignore tags etc.

> Can we develop a Scriptable Plugin with UXP?
You can use standard javascript features to add properties and methods. Same as any other javascript. I have not yet tried whether these additions would become available to other scripts. UXP in general also has means to address other "plugins" - keyword "Inter Plugin Communication", but I don't know whether these have already arrived in InDesign – Photoshop is leading here. Anyway it looks more complicated than addressing a target engine in ExtendScript. And it is less integrated than when you understand ScriptInfo resources, script providers etc.

[Chamari_Silva]

Thank you very much @Dirk Becker. I have a better idea now.