This is a user to user Forum, so you are not really addressing Adobe here, and I guess Adobe employees would not actually be at liberty to divulge that information.
Personally I see no reason why they should abandon this form of automation in Photoshop.
Thanks for your answer.
I understand they prefer not to divulge such info but some security that my work will not be useless in short time would be appreciated.
It's frustrating to have to change thousands of code lines in short time.
Some of Photoshop features are implemented using Photoshop scripts. So I feel scripting will be around for some time. Adobe CEO Shantanu Narayen has tunnel vision the only thing in his sight is the corporate customer all he can say is the creative cloud is of grate value to the corporate customer. I feel the the corporate customer is more likely to use script then the photographer. So you will continue to see more features like Picture Package a photographer's tool striped from Photoshop then a corporate tool like script which Adobe also uses. Script does seem to have its share of bugs that Adobe doesn't care to fix though. Photoshop is veering away from photography and becoming more a web development tool. ACR is where all the good innovation for photography is happening and it also nor a Photoshop filter as well as a plug-in. If Photoshop elements was not so striped down I would consider using LR and Elements. As it is now I'm struggling with should I just stick with CS6 and forget about new ACR features or sign up for Photoshop Photography Program. I'm getting tired of all the new bugs Adobe keeps adding in.
It makes sense to believe that scripting remains for corporate use and this seems the way it goes. Hope that the new Photography program will attract many of the not very happy now photographers to make them stay with Photoshop.
As JJMack said, their is a shift in focus at Adobe with respect to PS.
Adobe moved some photo oriented features that were implement in jsx to
Bridge several revs ago to a new scripting framework (AUM). See the Output
workspace in Bridge. They may have intended publishing the interface to
that framework but it never happened and it was more complicated than it
needed to be because you don't have the full PS/JS API available in Bridge.
Customers got really upset that Contact Sheet II was no longer supported in
PS, so they brought it back in a slightly improved form for CS6. However,
there is a slow degradation in the PS/JS implementation. Existing bugs
don't get fixed, new ones appear with each rev, and new features are
generally not well (or at all) supported in JS.
Scripting a UI is a mess. Each rev is slightly different than the previous
one. Automatic layout is such a minefield that I gave up within a rev of
its release. Then they added the Flash/AS mechanism and maybe something
else. Then there is the undocumented UI layout that their own scripts use
(Latte). And the not-quite-complete HTML stuff in ScriptUI. And no WYSIWYG
UI layout tools. My guess long term is that they are leaning towards HTML5
for the JS UI stuff which is fine, but I've tossed in the towel. I'll
maintain CSX, xtools, and Image Processor Pro for the foreseeable future
but I have no intention of doing any major new projects.
CS6 is still getting ACR updates and bug fixes so I continue to work there
in spite of the fact that I have a CC license for a year. I don't want to
inadvertently start using features that will lock me into CC and be screwed
when my license expires. Also, I sure don't need no steenkeen cloud. I'll
probably keep updating Lightroom, however, and may look into scripting some
stuff there if there is anything interesting that can be done there now.
thanks for your answer. I really appreciate it as I have learned so much from your posts and scripting techniques, thanks.
I don't believe that HTML5, which is the official new UI for CC next year is the best solution for large projects, but if js scripting continues and a way to create my own UI is possible then this seems the way to go.
Imho all the changes implemented for extensions and panels are only interesting for small projects with a reduced amount of UI.
Also, I sure don't need no steenkeen cloud.
On Fri, Sep 20, 2013 at 1:53 AM, c.pfaffenbichler
HTML5, which is the official new UI for CC next year
If you mean that Extensions are going to be coded in HTML that's ok - yet scripting should keep ScriptUI (which as X pointed out, is just a mess). But that also is, possibly, because there seems to be no "central authority" for scripting support in the various Adobe apps - each team, as far as I know, is in charge of the implementation of the ExtendScript specs in his own app - and as a result the behavior of the same code (especially when ScriptUI is involved) is really different, to put it mildly.
As for the scripting support in the future, I don't think it will disappear. CS6 has introduced Scripted Patterns for instance. Yet whether PS scripting will be a nice environment to develop into, frankly I can't say. To read that Xbytor won't undergo any major project but maintenance is a bit frightening - and Adobe's reluctance to put resources in bug fixing doesn't help.
The transition to HTML extensions could leverage the extensibility layer, the Generator project is really promising too - but I share to some degree a sense of uncertainity for my future as PS developer.
Mind you I mainly make my living with PS postproduction, so scripting is just an extra income for me. I wouldn't like to be in the position of a full-time dev.
Extension Builder and flex was a relatively good solution for creating the UI while scripting solved the complex processing, now UI should be made with html5 and I don't believe that this will work for large projects with many components and own code solving some OS and api related bugs.
As you wisely mention it's not the best scenario for a full-time developer, times are changing.
I guess my Scripting is modest in comparison to that of some of you, but DBarranca’s statement
there seems to be no "central authority" for scripting support in the various Adobe apps
got me in a venting mood with regard to Illustrator.
I feel that in the regard of Scripting implementation the Photoshop team is head and shoulders above the Illustrator team.
That I found many Illustrator features/tasks unscriptable might be (partly) my own fault, but maintaining Scripts’ inability to be assigned shortcuts and removing them from Actions on restarting for six (or more) versions seems just remarkable.
Then again to me the vector oriented application’s Path handling seems in some regards inferior to Photoshop’s – so what can one expect from Illustrator?
Even if it's not intuitive at first nor user friendly, ActionManager code is a life saver and God bless Tom Ruark for the ScriptingListener plugin - that's really something (I was quite surprised when I discovered that other Apps don't have their own ScriptingListener equivalent).
That said, PS rendering of ScriptUI window is by far the ugliest in the number - I don't remember if I've already posted this comparison elsewhere in the forum:
Clockwise from top left: PS, ESTK, IL, ID - all OSX but the latter. And I don't think HTML is going to be the panacea, at least in the short run.
I my own small way, I've started filling in bug reports in the Photoshop Feedback site (whose login system seems to be made to turn away users on purpose, BTW) and I keep pushing others to do the same. It is more true now than before, possibly, but to boost the probability that a bug will be fixed, users have to coordinate their complaints.
You should make a screen shot of ALL of the different versions of ScriptUI Photoshop has used over the years! And with this announcement, you should be able to figure out that ScriptUI (Flex based for Photoshop CC) will soon be getting a new adapter in the future. http://forums.adobe.com/message/5692258
ScriptUI for Photoshop, over the years, has had the following adapters (UI framework supplied to ScriptUI by the host application)
ADM (Adobe Dialog Manager) (I think this was the original)
OS (Default OS widgets)
Mondo (Internal UI framework that drives the UI for most of our plug-ins now)
Flex (Flash based UI widgets)
The changes were done for the following reasons: move to Carbon on mac, move to Cocoa on mac, move to 64 bits on windows, move to 64 bits on mac, we just like to change things and other reasons I don't remember!
I'm sure you don't change things just to liven up the otherwise boring days of the third party PS developer.
Yet for the formerly known Creative Suite, it's not unfair to have been expecting inter-app consistency in terms of behavior (not only look & feel). I'm sure too that we all (you and everybody in this forum) would like to have scripting bugs fixed, but management priorities are elsewhere - obviously.
Now, since the HTML announce went public and you are who we know you are in the PS team, could you please disclose (if you're allowed to) what this new adapter will actually mean? In the long term should we expect to have a rendering engine for ScriptUI windows that is platform independent (so what works on Mac will work on Win and viceversa) - or possibly CC app independent?
And lastly, are HTML extensions meant to replace scripting altogether in the long run (besides killing Flex ones nex year) or they will cohexist?
May I ask specifically if AppleScript and VBScript will continue working with new CC versions ?
Will an application be able to communicate through COM or applescript with PS ?
What we would like to have is consistent UI. The UI you get from Photoshop dialogs, our plug-in dialogs, our internal panels, our external panels (kuler), and ScriptUI dialogs would all look the same (widgets) and have the same behavior (sliders for example). That is a tough nut to crack as we get different pieces from different teams. And our apps have different frameworks. We, and third parties, do have pains associated with switching the "engine" underneath ScriptUI and we struggle with these decisions. Your best bet is to try and get into our pre release programs so you can see how changes effect your development workflows.
1 person found this helpful
Main problems are COM related (Windows) but I'll hope to find a reliable solution.
I just wish you keep a way to transfer paramterers between scripts and Native (C / C++) Code Plug In's.
I also wish you update and document this mechanisem as a solution to build UI for C / C++ based Plug In's.
That would be awesome!