Forcing everything to be async makes code much more difficult to write. There are situations where async API’s are useful, but for 90% scripts (particularly casual ones) it just makes it more difficult to write and debug.
The restrictions on APIs are painful. For example, there are many situations where opening things from hard-coded file paths are useful for a script, but the API restricts this case.
The documentation is missing. You usually have to record actions and reverse engineer the descriptors to access various Photoshop operations. This is much more tedious than just looking up the DOM functions in a reference document.
Question: what is the status of UXP Hybrid Plugins (i.e. being able to write C++ code for a DLL that gets integrated into a UXP plugin)? This is currently a blocker for me to implement certain features in CRDT_UXP.
Having that would make it vastly easier for me to add new features to Creative Developer Tools for UXP (CRDT_UXP).
Right now I make do with an external daemon to give the UXP code access to the stuff it needs (unencumbered read/write files, read environment vars, being able to launch processes,…) but having a proper DLL would make that much cleaner and efficient.
Also, how are things in relation to multiple UXP-enabled apps (Photoshop and InDesign, hopefully Illustrator soon?)?
Will the DLLs for UXP mutually compatible between apps? With ExtendScript, I can write DLLs that are compatible with all ExtendScript enabled apps, and I sure hope that the UXP DLL infrastructure is similar in that respect!
What I would hope is to be able to write a single UXP DLL that would work with all host apps that support UXP.
I only just started with UXP, i might be mistaken. I am blocked by
Indesigns Enumerators not beeing present, or the way they work, i have to use the values or write conversion routines.
i miss toSource()/eval as a way to store data in scriptlabels or local files. I can’t get JSON.stringify to properly store and remake for instance transformation matrices or the mentioned enumerators. Someone mentioned structuredClone - That would be great i guess.
A missing runtime object model watcher. I don’t know how i wrote ANY script without one at all, since ESTKs demise.
Documumentation … please, or more samples with some reusable good practises patterns (plugin-examples, NOT .idjs)
the Spectrum Widgets input field is not as comfortable as the ScriptUI Editboxes, i get weird behaviour.
@Erin_Finnegan Thanks for asking for this type of input. We were initially excited about UXP (modern JavaScript and no zxpsign!), but we are hurting from the loss of a Node.js environment. UXP seems to be a ways off from feature/capability parity with CEP. Here’s a list of what’s needed for us to adopt UXP and support the required features of our existing CEP Extensions. Some of these echo what others here have already mentioned.
Please let us know if any of these have been implemented or fixed and we just missed that in the docs.
Blockers
Ability to send system calls (child process)
We will try Bolt-UXP’s hybrid plugin that provides execSync(), but we support a number of internal CEP extensions on macOS and Windows. Building either a Helper app or hybrid C++ plugin just for this functionality seems like a lot of overhead.
Our plugins are internal to the studio and will not be distributed in the plugin marketplace. It would be nice if there were some sort of feature toggle that would allow exec calls and full file access for this type of plugin.
Ability to whitelist a helper app in configuration without requiring user consent initially and with each new plugin version. (if we have to go the route of building a helper app)
Plugin preference to grant permissions and not require user consent for file access for each version
localFileSystem and tokens do address this somewhat. However, the way it is implemented is not in the same manner as other fs implementations such as in nodejs. This means that some otherwise useable node modules would not be compatible with UXP.
CSS Features. SWC is ok, if it was fully implemented, and if the SWC-UXP-Wrapper surface covered all SWC.
For example, text-transform: uppercase and text-transform: none
Transitions on popovers and toast notifications.
Flexbox
Drag and drop
Drag and drop from one area in a panel to another inside the same panel.
Also drag and drop from within the panel to the InDesign page.
Blockers from the List of Known Issues
When rendering inline text that wraps, borders, outlines, and backgrounds only apply to the first line. You should place borders, outlines, and backgrounds on elements with block layout semantics.
Block level backgrounds are not an option. We need to be able to style the background of spans.
Save, file open, and browse dialogs appear behind plugin
Infinite clicks from displaying a dialog or file picker from button
Items Requiring Less-than Desirable Workarounds
Text field password does not hide text input on macOS.
The recommended workaround is not viable.
Interactive elements swallow events.
If this means onClick events are not bubbled up past their element, this is a problem.
Text field z-index. Text fields and areas will always render the above everything else in the same panel or dialog.
This sounds undesirable for text fields on a scrollable page where we would need to hide them manually under headers and footers.
Wishlist
Document storage (XMP or equivalent for arbitrary data)
We rely on writing data to custom XMP namespaces in InDesign documents. This data needs to travel with the file between users, so local storage is not an option.
Better Hot Module Replacement (Reloading) in UDT in the pattern of bolt-uxp
Ability to run a series of commands that don’t get added to the undo stack at all. Could be either by pausing and resuming the undo queue, or explicitly sending a doScript command that is not undoable.
Examples: Collecting information from the open document, reading/writing XMP metadata, going to a specific page, selecting text, etc…