I would like Adobe ExtendScript back, who's with me?

[studiovanzwet]

Hope you agree.

[Peru Bob]

I've moved this from the Using the Community forum (which is the forum for issues using the forums) to the Lounge forum.

[Nancy OShea]

ExtendScript is obsolete and unsupported.  And the Toolkit won't work on modern Macs because it's so old.  But you don't need permission to keep using ExtendScript.  There's an extension for it for Visual Studio Code.

https://marketplace.visualstudio.com/items?itemName=Adobe.extendscript-debug

[Moderator moved from The Lounge to Coding Corner.]

[studiovanzwet]

I know and I have it installed, but I like ExtendScript Toolkit beter, aspecialy the Object Model Viewer. Why not make a new version that runs on newer Macs? Is there a solution not to type te name of your script every time you run debug in VS Code extension?

[Nancy OShea]

I don't work for Adobe.  No one here does.  But I suppose it's because ES Toolkit is ancient.  And Apple has ended support for 32-bit apps.  It's hardly worth throwing time & money at an old FREE app that few people use anymore. 

When you need to keep using old apps, you should keep an old computer or virtual machine on hand that can support them. Also never upgrade that machine's OS.

[Erin F.]

I don't work for Adobe.  No one here does. 

🙋🏻‍:female_sign: Wait I work for Adobe, and I'm here!

A surprising number of people still use ExtendScript Toolkit, despite its flaws, and many of them, like @studiovanzwet, really miss the Object Model Viewer on their new Macs. There is a long history of why ExtendScript Toolkit was abandonded, and then not hauled forward into the present day... 

Fortunately, my team has been funding a big update for the VSCode debugger because we realize how many people are now dependant on what was meant to be a short-term tool. I don't have a release date just yet.

I agree - you shouldn't have to type in the name of your script every time! 

[Chuck Uebele]

I still use ESTK and love it. I tried the VS code, but like you said, having to type in the name each time seemed really odd and inconsistent. I often just do little test and don't even bother saving the script. 

[Zesty_wanderlust15A7]

Why are so many helpers repeating no Adobe employees come here, as if it's a mandatory script?

IIRC, elsewhere it says the ones with the Adobe badge are. In fact, one replied right after you...

 

[Nancy OShea]

@Zesty_wanderlust15A7 

Most people have the false idea that we are all Adobe employees.  In fact, Adobe staff rarely participate in these user-to-user communities.  Most interaction is between customers with questions and fellow product users.  We try to make that clear to everyone so as not to leave a false impression.

If that was your question, I hope I answered it.  If not, please see links below.

https://helpx.adobe.com/x-productkb/global/community-tips.html

https://community.adobe.com/t5/using-the-community-discussions/adobe-support-community-guidelines/td...

[Zesty_wanderlust15A7]

"Most people have the false idea that we are all Adobe employees."

> I understand that, but that's no reason to turn it upside down as if there are none. I see plenty of people with the badges — almost in a majority of threads if they seem/become important. To claim there are none is just Twilight Zone and feels like a weird agenda to me.

If people think you are payed, then plead to remove the "Adobe Community Professional" titles, etc.

What's happening now feels like pure disinfo.

Adding a ton of credits in a sig doesn't help to look a "normal user" either.

You could start with, "Although Adobe employees might see this, or visit in their free time, most of us are..."
I suspect you guys get a form of payment, as you should — like maybe being allowed to include all your credentials & stuff. But then you will appear employed.

[Nancy OShea]

Not sure what your point is or if you even have one  but it's falling on deaf ears here.  This topic is a year old and the principle participants have left the room by now.  

Do you have a real question?  Or maybe something useful to contribute to the actual topic that hasn't been said?  If so, I'm all ears.  If not, I think we can conclude this now.

[Lumigraphics]

Year and a half later, still desperately need an omv file parser and Apple Silicon-native extensions.

VSCode is ugly, not a native Mac app, a PITA to use (had to turn off pretty much everything "helpful" in the Text Editor) and my preference would be to use XCode on the Mac. :sigh: ESTK had a lot of problems too but what we have now isn't much better.

[Bruce Bullis · Accepted solution]

Your concerns are valid. I loved ESTK too.

It's dead, and is not coming back. 

I'm sure you're aware that all Adobe applications are moving from extensibility based on ExtendScript + CEP, to extensibility based on JavaScript + UXP; some have already moved. This makes additional investment in ESTK even less likely. 

Ugly? Perhaps. It's also very customizable. You can make comments appear in Comic Sans, just like ESTK did, if you like.

Not native? Okay, but literally hundreds of PPro partners use VSCode + ExtendScript Debugger on Windows and Mac ARM systems, every day, without issue. 

PITA to use? Perhaps; your mileage may vary. I prefer the debug configuration options the ExtendScript Debugger provides, over ESTK's old target selection pop-up. 

XCode on Mac? Adobe partners require a cross-platform solution.

The VSCode ExtendScript Debugger running in VSCode is, admittedly, an imperfect solution; it is also the path forward. 

[Lumigraphics]

LOL I didn't love ESTK, it was a non-standard mess too.

There is a very poor custom by some developers to write an app with a "cross-platform" toolkit and call it good enough. On Windows, that's usually fine but on the Mac, we want a better effort. Look at Apple's yearly design awards and see if you can spot non-native custom controls, cross-platform UI frameworks, Windows conventions, etc. I'm sure you know the answer.

Having said THAT, what I'm most concerned with is functionality. My workstation at home has a nice M1 processor but I have to use my 2015 MacBook Pro with VSCode because the debugger isn't Apple Silicon-native yet. Three years after the M1 came out. So, no, not ok.

And instead of dismissing XCode, how about supporting multiple environments? VSCode, XCode, let me use Notepad++ or BBEdit if I prefer.

And what about OMV files? That was the most useful part of ESTK, considering that Extendscript documentation ranges from missing to barely usable to incorrect to gawdawful.

I'm not trying to be negative here, I've put hundreds of hours into developing Apache-licensed scripts that I use in my day job as a product photographer. I want all of this to improve and be more workable.

So: M1 native debugger, OMV parser (and up-to-date OMV files), COMPLETE AND CORRECT documentation (how about a big fat pdf for Action Manager code?), better sample code and examples, scripting bugs fixed and functionality added... that would be a good start and help all of us who are, bottom line, helping you write your software.

[Bruce Bullis]

> My workstation at home has a nice M1 processor but I have to use my 2015 MacBook Pro with

> VSCode because the debugger isn't Apple Silicon-native yet. Three years after the M1 came out.

> So, no, not ok.

I don't understand why the non-nativity of the debugger is a barrier; specifically, what actual problem(s) does that generate for you? I'm genuinely curious, as none of PPro's hundreds of partners has ever said this is an issue for them. Like them, I use VSCode + ExtendScript Debugger on my multiple M1 machines, to debug ExtendScript in PPro (running ARM-native), every day, without issue. 

> I'm not trying to be negative here

Appreciated; likewise! 🙂

> And instead of dismissing XCode, how about supporting multiple environments?

Because investing in supporting multiple dev environments for a technology that's already been deprecated and superseded (ExtendScript) would diminish and detract from Adobe's efforts to improve and modernize extensibility, across all applications. 

OMV: Yep, that's a shortcoming of VSCode. It's unlikely to return.

Action Manager: Sorry, no clue. ¯\_(ツ)_/¯

Better sample code, and examples: Always desirable. Wouldn't those be specific to the application(s) for which you're writing integration, and not the dev environment? Ideally, what samples would you want Adobe to create, that aren't available today? "I'd like to see example ExtendScript for [some app] that [does some thing]..."

I can't speak for every product, but my PPro team does maintain/curate/improve documentation and example code that thoroughly covers and exercises PPro's ExtendScript API. 

[Lumigraphics]

Yeah I don't use video apps, I'm a working professional photographer who uses Bridge and Photoshop in production. I publish a package of utility scripts for Bridge and some odds and ends for Photoshop, all F/OSS because why not.

On my M1 I can run VSCode in Rosetta if I have to but performance is better when run natively. Since Bridge has to be quit and relaunched for any changes to loaded scripts, it really helps to be able to run snippets from VSCode directly in Bridge via the debugger. Photoshop doesn't have this problem, once a script has been loaded once, you can replace it with Photoshop running and invoke it with the changed code.

Action Manager is one of the APIs for Photoshop, along with the DOM. A LOT of what scripters can do in PS requires Action Manager and documentation is almost non-existent.

Us long-time Mac users have been down the road of relying on third-party apps and having this be problematic (we can go all the way back to THINK C, Codewarrior, Internet Explorer for Mac, and so on) so its frustrating to have to use another tool for coding. XCode beats the pants off VSCode as it should. I get it... but still.
You could write a stand-alone OMV parser. Its XML. We really could use it.

As for samples, having written a bunch of Bridge scripts, well... let's just say I've figured most of it out by myself.

[Bruce Bullis]

>Since Bridge has to be quit and relaunched for any changes to loaded scripts,

?! Are those scripts in a CEP panel, or loaded through some other mechanism? If they are in a panel, a refresh button in your panel's JavaScript, will reload updated ExtendScript; see PProPanel (a truly awful-looking sample panel that uses basically all of PPro's ExtendScript API) for an example.

>  it really helps to be able to run snippets from VSCode directly in Bridge via the debugger.

Agreed, I do that (but in PPro) several times a day. 

> Us long-time Mac users...I get it... but still.

As someone who once ported the AE SDK sample projects from Dev Studio to CodeWarrior Windows, I completely understand. 🙂

[Lumigraphics]

All of my scripts are pure Extendscript, no CEP or UXP. I've done web development in the dim and distant past, at some point I have to jump into UXP and see how it works. Not much spare time at the moment. There is no way to load an updated Bridge script except quit/relaunch, unfortunately.

I'm not really a coder, despite college credits that say otherwise. I'm more an amateur who needed Bridge to do a bunch of things that it couldn't. My most recent (not quite finished) project has been to integrate EXIFTool with Bridge and Photoshop, since I found out the hard way that Adobe's XMP Toolkit has some gaps.

I'm not sure if you have any pull but I will suggest that someone in Adobe's dev tools/evangalism team swing through the Photoshop, InDesign, Illustrator, and Acrobat forums and ask for scripters to give feedback. I bet you'd get a load of good comments. There is also ps-scripts.com where some of the more knowledgeable folks can be found.

[Bruce Bullis]

[Yeah, it seems my 'reload the panel' suggestion wouldn't help reload your Bridge ExtendScript...]

I have very little 'pull' outside of DVA (Adobe's Digital Video and Audio group; you know, the cool apps, haha), but happily our Extensibility team actively works with every point product, on how best to support their developers. 

[Chuck Uebele]

Yea, @Lumigraphics, my scripts are now all extendscript. I did a couple panels with CEP, I believe, but a lot of work for just things for me. I tried putting a few on the exchange, but then you start getting people complaining that it may not work with their system, or they want it designed differently, and I just didn't want to deal with all that. Plus Adobe has a record of releasing something then dropping it. I just did want to spend all this time for something that might be discarded.

[Erin F.]

All of my scripts are pure Extendscript, no CEP or UXP. I've done web development in the dim and distant past, at some point I have to jump into UXP and see how it works.

These days there is UXP Scripting for Photoshop. You might want to check that out, as Photoshop will eventually remove ExtendScript: https://developer.adobe.com/photoshop/uxp/2022/scripting/ 

I'm not sure if you have any pull...

I think @Bruce Bullis has some pull with my team...

...but I will suggest that someone in Adobe's dev tools/evangalism team swing through the Photoshop, InDesign, Illustrator, and Acrobat forums and ask for scripters to give feedback. I bet you'd get a load of good comments. There is also ps-scripts.com where some of the more knowledgeable folks can be found.

😅 As a dev tools/evangelism team member, I assure you I am monitoring those forums (OK, not the Acrobat one, that's out of my purview) and have been fore about 5 years now. I've been interviewing developers for the last 6 months with our team's executive to gather feedback.

Action Manager is one of the APIs for Photoshop, along with the DOM. A LOT of what scripters can do in PS requires Action Manager and documentation is almost non-existent.

If you're still using Action Manager code via ScriptListener I have good news!!

These days you can use batchPlay and a free third-party extension called Alchemist to listen for events and output more useful code. The Alchemist developer and people using these tools hang out in our new UXP-focused developer fourms.

You could write a stand-alone OMV parser. Its XML. We really could use it.

I spent a chunk of time last year coordinating putting InDesign's OMV on a webpage here. We translated it from XML to Gatsby and it kind of broke things on the backend, and it isn't perfect. Gregor has an InDesign OMV site he's been maintaining for years.

I've been trying to drum up the funding to both:

1. Get the VSCode Debugger working on M1 and

2. Add an OMV parser to the thing

However, at the moment internal teams are not resourced to work on anything other than the latest and greatest initiatives; there's not a lot of time or resources left to maintain tools that we're actively trying to replace.

[Lumigraphics]

You'll have a revolt if you kill Extendscript on Photoshop. Oh boy. A LOT of people rely on it in production. I do get the shift to UXP, but for those of us who aren't dedicated developers, we just need something that's easy to use and works. I'm first and foremost a working professional photographer, not a developer. I don't want to write a complete plug-in for simple stuff that I need automated.

For example, I maintain product photos, some of which have text overlaid. I was easily able to write a script to do find/replace on thousands of PSD files, with a couple dozen lines of code. Writing and packaging a UXP plugin just for that seems overkill and would be a huge waste of my time. I have other utility scripts that are just a few lines long. Those of us who actually work in these apps NEED that kind of functionality.

I have seen mentions of Alchemist, if I ever have spare time to learn more/new coding I'll jump into UXP. I also want to find the time to learn Swift for macOS and iOS coding but again, not enough hours. And I use Lightroom Classic for my freelance/hobby business so I want to do some things in Lua... :sigh:

Eventually, Intel will be gone on Mac and Rosetta 2 deprecated. Hopefully the toolchain is native by then.

[PECourtejoie]

Yes, in my day to day work, I do rely on several scripts that run in Bridge, some by David, some are simple copy filename to title, Some are search and replace in Bridge, etc. If extendscript is to be retired, I seriously hope that developers will have enough time to convert their work to the new language, or many users will be stranded. 

[schroef]

Is there already a full documentation as like ExtendScript? I feel like they are pushing to fast towards UXO without proper documentation being ready. Is there for example a github like CEP has

[Bruce Bullis]

There is no documentation, because there is not yet any 3rd-party accessible UXP extensibility in Premiere Pro. 

I'm curious where you see push to UXP, in Premiere Pro...?