Photoshop Actions And Javascript Clarification Please

Yes indeed. You have to because CEP jsx isn’t supported in UXP.

1 Like

Thanks for the clarification.

Looks like some long nights lie ahead then.

:smiley: Yep, after a few weeks of observation, deduction and experimentation you should get more comfortable with UXP logic :wink:

If you don’t care about the user seeing the action steps then you always have the option to have UXP play the actions.

I have a few actions that I never made into CEP panels because of just the overall amount of steps in the actions. For those, what I’m planning to do is to break the actions out into several actions. Between the actions, UXP coding will do the steps needed for the adjustable things from the user UI input. Anything that is just repeat “as-is” will played as an action.

Just an option…

Am I right in thinking that the Actions would still have to be present in the users Action Panel for this to work.

Yes, but be aware that there’s currently no way of programmatically opening Action-files.

True, but UXP can play the actions. You have to have the user install them however.

Installing them is pretty straight forward with an installer. The issue would be if at some stage, they deleted the actions and the UXP panel would stop working.

Ive just been looking at some of my actions and they have a ton of individual steps which is going to make it tedious to record in Alchemist.

Such a shame that we cant do what we did before when we outputted the actions to a JS file and use that.

You can have it check for the action and then prompt them to reinstall. You can even have it check at plugin load and it the actions don’t exist have it hide/show divs so instead of the UI they have a message to install the actions. You can also have it run the check when they run the program. However, the issue does exist still if the user modifies the action and breaks things.

Is anyone likely to turn round and say…
“Why the need for the Panel if I can simply run the Action which you have installed in my Action Panel”

Just thinking out loud here of scenarios

It would depend on what your actions are doing. In some cases maybe yes but in other cases no.

I have a set of actions where there are 42 actions because of different paramaters needed to adjust based on image size, direction, and density. Instead of 42 action, I could reduce this to 3 actions and then have the UXP coding handle direction and density based on user input. The sizing wouldn’t be needed because the UXP could get the image size and automatically adjust for things. So in this case there would be 3 actions that get played along with 3 places in between the actions that do a few steps to compensate for the parameters. The end result is a much easier user experience and more control too for more precise density other than just 3 settings.

So in this case, while the user would have 3 actions, they wouldn’t be able to put it all together anyway because they would be missing the important pieces of the puzzle which are the adjustment steps done by the UXP code. Sure, some people may figure out what is being done in the actions and be able to piece there own together. But that isn’t something I’m worried about for a bunch of actions I have that I want to use this method for.

I’m not saying this is the best solution for everything. I also have 10 plugins that won’t have any actions at all and are much more proprietary. However, the action method is an easy solution for things like this that are less proprietary and where the ROI to build it all in coding isn’t there to justify the workload doing it.

Psst! We’re dreaming about ways to bundle Actions & UXP Plugins together so that you don’t need to worry about installing them separately and the like. No firm details yet, but it’s something we’re actively working on.

Also UXP plugins themselves are going to become recordable, so that opens up the option for even a single Action that then invokes your UXP plugin at the right time. Lots of interesting potential here. :slight_smile:


Thank you for this feedback :slight_smile: Both of those things are very welcome changes.

The action recordability option is something that I could really use. Some of my programs are JSX only but appear in the PS Filter menu and are more like “plugins” to the user. I use the javascript resources and terminology tags in the startup JSX script file to make the programs recordable with actions. Not being action recordable has already become a complaint from quite a few users with the switch to UXP for all of my programs.

Photoshop Action to BatchPlay Script…

Now that would be a nice option until Adobe implement something.
There must be some WhizKids wih plenty of time on their hands out there whilst we are in lock-down that can do this @Jarda :slight_smile:

I have no plans to do that in the next 3 months.

hi Kerri, I think that Adobe will have to think and plan very carefully on this point. There are large independent repositories of commercial Actions - like this one: Envato Elements | Unlimited Photoshop Actions - which would provide for all sorts of automated wizardry to be transcribed or incorporated into UXP Plugins, without authorization.

I don’t understand your point.

Anyone could do that even before UXP. There are converters for that for years. Also .ATN file binary format is documented and anyone can write parser. Also in actions itself you can see details about steps and parameters in PS UI. It can be replicated even without a convertor tool and if you do that from scratch I am not even sure whether workflow/steps can be even protected.


Yes - all of that is true. But Adobe themselves took no part in any of it. Everything that could be considered to be a transcription or transfer of any Action was done by independent developers and users (and some thieves!).

I understand your concerns. However, IMO, it makes no sense to hold back a game-changing feature like this based on those concerns. Actions can already be easily be replicated just by making the same steps in batchPlay that are in the actions. With that said, I don’t think that most people who are writing plugins are looking to make carbon copies of actions they find online.

Integrating actions into UXP makes a lot of sense from a programming standpoint. As someone who creates both commercial actions and plugins, I can see huge potential in integrating them. I already have a dozen or more use cases lined up for this if it happens.

Actions are very limited because they can’t think or perform logic. Plugins can do so much more but are so time-consuming to create for complex workflows. Integrating these 2 features would allow much simpler creation of complex workflows with the ability to add adjustments and logic. For me, it seems like a “no-brainer”.

It could even open up a new market for action creators to step it up a bit and create better things than they could make with only the limitations of actions.

1 Like

Actually, I think that converting .ATN into UXP panel will offer better protection. You can hide history. You can try to obfuscate code and workflow steps won’t be described in UI. So that would defeat non-devs. But there are still ways to listen to events made by other panels. That would be like action recording but not for manual work but someone else script. But it requires some skill. So I think that authors of .ATN actions should convert that and get rid of .ATN files for their own sake. If this would require zero skills then good for them.

1 Like