Action Manager Update

[Ghoul Fool]

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...

[Dariusz1989]

+1 from me too, can we get some clarity? 

[Ghoul Fool]

Two months and yet no response or further clarification.

[c.pfaffenbichler]

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. 

[Lumigraphics]

And then things will get ugly.

[c.pfaffenbichler]

»Adobe giveth and Adobe taketh …«

But like I said: »If I understood correctly«

I am not sure where exactly I read about this, so I might be mistaken and the timeline had not been published anyway. 

It might be a couple of versions off even if it ultimately happens. 

[c.pfaffenbichler]

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

[Davide_Barranca]

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

[c.pfaffenbichler]

@Davide_Barranca , thanks for chiming in! 

Considering the documentation Adobe themselves provide I think a plug for your book may be well justified. 

[Dariusz1989]

Oh boy, this is quite dramatic, I do hope tho they will keep MFC and afx library in windows for c++ interation/com system etc ;c

I looked at UXP and as "nice" as it is, I don't see plugin in c++ where I can create upx engine and run code from plugin side like we can with javascript engine, hope they will add support for it!

[Davide_Barranca]

I'm not sure I understand what you mean there I'm afraid. You can create hybrid plugins, where you hook directly into C++ functions from the JS side (and vice-versa). Think about glorified "ExternalObjects". Recently, at least in Photoshop, Hybrid can also tap into the Photoshop C++ SDK.

[Dariusz1989]

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

[Ciccillotto]

From what I know c++ is supported by uxp. However, for further information, ask in the appropriate forum

https://forums.creativeclouddeveloper.com/c/photoshop/63 

[Jesper Storm Bache]

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++/

[Ghoul Fool]

But in terms of legacy scripts (like Load Files into Stack.jsx - for example ), will they continue to work or will everything have to be re-written for future versions?

[Ciccillotto]

To date we don't know how Adobe will proceed and we don't even know when we will definitively switch to uxp, they will certainly have to rewrite all the code, alternatively the existing code will remain available but javascript can no longer be used.

[Davide_Barranca]

Scripts bundled with PS will be ported by Adobe in time for the ExtendScript EoL—Jarda and I did some of them last year as part of our consulting gig for the UXP DOM, but they haven't been published yet.

[Lumigraphics]

So those of us with a bunch of utility scripts already written will be hosed? Lovely.

[Ciccillotto]

unfortunately they will no longer be usable.

[Davide_Barranca]

That's what happens when a new environment replaces an old one, I'm afraid—I feel your pain.
On the other hand, it's not going to happen overnight (again: I am speaking without any insider knowledge of the matter, mine is just an educated guess); UXP has been introduced in late 2020, developers have already been given a few years to familiarise with it.

Friends who work in enterprise environments tell me that porting the old codebase into the new platform is ensuring them years of paid work ahead 😉 

[Lumigraphics]

:sigh:

I'm not really a developer. I'm a working pro photographer using Bridge and Photoshop to make a living doing in-house product photography. I've had to write dozens of scripts to fill the numerous feature holes in both products. I also use third-party scripts quite a bit.

Here's a good example. We use "BOM" photos on our production lines as a visual reference, so associates can see which parts go into a product. I recently needed to add weight and vendor part numbers to many of these photos.

I pulled part data from our production database, used Paul Riggot's DIY Metadata Bridge script to write the data into XMP, then a 180 line Photoshop script I wrote to create a formatted, aligned text overlay on each photo, then saved the finished PSD and exported a JPEG. Without scripting, I'd never have this done. Ever.

The end result looks like this... and I have no idea how to re-write that whole toolchain as UXP. Nor do I want to waste the time.

I really, seriously hope Adobe doesn't crap the bed AGAIN and not provide migration tools.

 

[Ciccillotto]

from the model I see it is very simple to do it in uxp.

[Lumigraphics]

Ok but I don't know anything about UXP and honestly don't have the interest to learn. I need solutions not homework.

[Ciccillotto]

sorry for the question but now how do you program, do you use actions do you use javascript or what?

[Davide_Barranca]

Ok but I don't know anything about UXP and honestly don't have the interest to learn. I need solutions not homework.

By @Lumigraphics

Given what you've written ("I've had to write dozens of scripts to fill the numerous feature holes in both products.") you qualify as a developer 🙂

You may not have been formally trained as one, but it looks like developing/using scripts is an important part of your profession. If this is the case, learning UXP seems to me the best way to future-proof this branch of your business. Alternatively, if you're more solution-oriented, the quickest, B2B way is to hire a developer to build the features you need for your job. In case, you can't go wrong with Jaroslav Bereza.