Action Manager Update

Forum|Forum|2 years ago
November 9, 2023
4 replies
3163 views

I came across this post of GDSE and now, it nearly being the end of 2023, can anyone confirm or deny if this (unsourced) statement "...Action manager won't be supported in newer versions of Photoshop." is true or not??

Is this a random rumour? Or is it anything that Action Manager coding fans should be concerned about? Clarity with an explantion is due.

The truth is out there with a side order of cookies...

This topic has been closed for replies.

c.pfaffenbichler

Community Expert

@DavideBarranca , please forgive the intrusion, but could you clear up this query?

Davide_Barranca12040269

Legend

For AM to be unsupported, the whole ExtendScript language should be dropped, which I doubt will happen anytime soon. I have no insider information to share, but my sense is that we might enjoy a few years of backward compatibility with the old system.
OTH, AM like a phoenix is now found in ActionJSON (also known as BatchPlay), in the context of UXP scripting (and UXP plugins). Same exact stuff, different (easier) syntax.
Shameless plug: I've published a new book on the UXP Photoshop API titled "Professional Photoshop UXP", which covers (also, and in great depth) exactly that topic.

Hope this helps!

—Davide Barranca

Davide Barranca - PS developer and authorwww.ps-scripting.com

Jesper Storm Bache

Adobe Employee

Here is our current workflow

c++ plugin

scenario 1. Rapid development

c++ plugin calls custom javascript engine>

err = sScriptingSuite->CreateEngine(&engineRef);
...
err = sScriptingSuite->ExecuteScript(engineRef, unicodeCommand, kJSExecutionModeNoDebug/*kJSExecutionModeNoDebug*/, &result);

scenario 2. Performance

We write the entire logic in C++ after verifying it works in javascript 1st, this usually happens when we need more perf than what we get in javascript.

If I can't create a UPX engine and pass code as byte/string(not file paths) to it from C++ then we will have a very bad time :- (

Its in-house solution/etc so we don't want to go to Adobe store/etc/etc.

I know UPX can tap into c++ lately which is great, but we also need it to run fully from c++ in custom engine.

Can adobe extend c++ plugins to support the creation of UPX engines like javascript, please?

Or at least be able to send code from c++ to UPX directly and have it run there.

One thing we love a lot in c++ & sScriptingSuite is that whatever we return from that custom script can be retrieved from c++ as it's a simple string, awesome, hope UPX can match that too!!

err = sScriptingSuite->ExecuteScript(engineRef, un, kJSExecutionModeNoDebug/*kJSExecutionModeNoDebug*/, &result);
PIUASZString aszResult(result);
const ASUnicode *unicodeResult = aszResult.GetUnicodeString();
ASUInt32 unicodeLength = aszResult.GetUnicodeStringLength();

std::wstring resultString;
for (ASUInt32 i = 0; i < unicodeLength; ++i) {
    resultString += static_cast<wchar_t>(unicodeResult[i]);
}
returnMsg = icu::wstringToString(resultString);
if (err == kJSScriptExecutionError) {
    showError(ag::ps::failedExecution);
}

^ our actions usually just return json.dump string that then we can load in c++ and do what we want with the result.

Regards

Dariusz

As Ciccilotto states, you can combine UXP JavaScript and C++ (https://developer.adobe.com/photoshop/uxp/2022/guides/hybrid-plugins/)

As opposed to your example where you create temporary ExtendScript javascript engines, you are likely to want to reverse the model:

Have a single UXP (javascript) plugin that runs the JavaScript (unoptimized) functions. Then you can optimize sub-functions by implementing in C++ and then have your JavaScript plugin call your native C++ functions instead of the equivallent JavaScript funcitons.

When you get this up and running, you may find that UXP (and its V8 engine) is significantly faster than ExtendScript and you may have to move fewer functions from JavaScript to C++/

c.pfaffenbichler

Community Expert

If I understood correctly then its not AM-code in particular, but ESTK Scripting altogether that is on »legacy«-staus and will, at some unkown point in the future, be removed altogether, thus forcing the switch to UXP Scripting.