Copy link to clipboard
Copied
Copy link to clipboard
Copied
What are you referring to by a "custom panel" ... one created by perhaps a scripting operation?
As I can't replicate this with any panel 'native' to Premiere, not even the Red Giant Universe plugins when opened as a panel ...
Neil
Copy link to clipboard
Copied
custom panel = CEP-based panel, hosted in an Adobe point product. The Red Giant Universe Dashboard is an example.
Copy link to clipboard
Copied
Also = Custom Extensions you can download here: https://exchange.adobe.com/my-exchange.html
Here's a link introducing it way way back in 2013 (older than I realized)
If I can sing their praises: A lot of things that you wish an editing system can do can be made to happen with custom extensions. Connecting an external data-based logging system to augment the Project panel, integrating transcriptions, exporting reports, automating transcodes and exports, naming convention assistance -- endless.
To replicate with a 3rd party extension -- one I didn't build -- I used "Property Explorer" (thanks Sir Editor who suggested it) but there are plenty more.
Copy link to clipboard
Copied
You're always welcome to ask questions.
As you've guessed, no progress has been made toward B-125639.
As a design principle, Adobe's applications rely on user interaction to activate panels. [We're selfish about activation.]
It's likely that Adobe won't fix this CEP issue, prioritizing instead our move to supporting UXP extensions, which have a very different host UI interaction model.
Sorry to not be more helpful, with the enquiry.
Copy link to clipboard
Copied
> Sorry to not be more helpful, with the enquiry.
Always helpful. Thanks. I'll make it work.
RE UXP extensions... What actually is (or will be) UXP extensions?
In an earlier post you distinguished it from New World Scripting.
What is the difference between the two?
For that matter why UXP and New World vs Classic Custom Panels?
Will UXP be an upgrade of custom panel scripting -- based on JS, or is it something entirely new?
Copy link to clipboard
Copied
New World = calling existing ExtendScript engine, through the "new plumbing" through which we also call the modern, V8-based scripting engine we'll use for UXP.
Not an intended change, but the New World doesn't perform default type coercion (to string), so you have to pass in the right param type.
UXP = Whole New Thing™. Adobe XD is the only application shipping a UXP-based API, but that will change soon.
https://adobexdplatform.com/plugin-docs/
One key difference: In UXP, instead of a JavaScript (CEP) layer and ExtendScript (host app scripting) layer, there's just one (JavaScript) layer.
Copy link to clipboard
Copied
The countless hours devoted to figuring out how to properly pass data back and forth between front end and back end (or JS layers anyway)-- and now you're saying that skillset is just goes into the dustbin of history? Very much looking forward to that.
What about existing extensions built on the 2-layer (JS/JSX) architecture?
Will they need to be converted to single layer?
Will UXP use the same API or allow for easy migration, or is it an entirely new API requiring considerable code conversion?
Copy link to clipboard
Copied
> What about existing extensions built on the 2-layer (JS/JSX) architecture?
Existing CEP extensions will continue to be supported, until many months after UXP extensions (which the UXP team insist on calling 'plug-ins' even though they are demonstrably not plug-ins, which are by definition compiled, but are rather interpreted extensions) start being supported.
> Will they need to be converted to single layer?
UXP plug-in versions of existing CEP extensions, will need to be written. 🙂 As soon as PPro builds containing support for third party UXP extensions plug-ins become available, we'll spread the news far and wide.
> Will UXP use the same API or allow for easy migration, or is it an entirely new API requiring considerable code conversion?
The plan is for the current ExtendScript API to be available to UXP...plug-ins.