Seems like a good idea, but I wonder...
Given such a complex application that's been developed for so many years for interactive use... People would want to go do other things with the computer, right? That's the reasoning behind this. Yet I'll bet there are checks all through the code for whether the Control key is being held down, what the mouse is doing, etc.
Right now today if you run scripts or actions, and you do other things with the system, you find things go wrong. Functions that are modified by the Shift key get modified, etc., because of other activity the user is doing.
Though it's easy to conceive of what you're saying, the actual task of implementation (of disconnecting Photoshop completely from the desktop) would likely be harder than it looks.
People would want to go do other things with the computer, right?
No, that is not right. Here is my intended purpose: What I am trying to do is run a copy of Photoshop Extended on a server as part of an Action playback server.
This would let my design colleagues record an action for a specific type of raw file, then attach it to a workflow for automatic playback on other raw files of the same type. This Action Playback Server would run on a dedicated rack server--there would be no user at the keyboard to interfere with its operation.
Not saying Photoshop shouldn't ideally be able to do this, but given the age of Photoshop's code base and the way it has grown over time, I imagine that the value provided by that feature wouldn't even remotly justify the resources required to develop and test it.
But why would the splash screen, random progress bars and other things popping up on a server from time to time be an issue if nobody is interacting with it through regular input devices anyway? As long as the UI doesn't require some kind of manual input or confirmation, what is the problem?
The problem is that the splash screen, progress bars, etc, keep Photoshop tied to being launched from a desktop—that is, attached to a logged-in user session. Without them, it could be run as a background process.
What is wanted here is that if Photoshop is being run by a program or script instead of a desktop user, Photoshop should communicate with the program or script directly instead of using the screen. That gives the caller complete control over what Photoshop is doing.
Ok, I see. Depending on your problem, if it doesn't have to be Photoshop and you just need a powerful image processing solution, you could look into Autodesk Composite (formerly known as Toxik) or Apple Shake. Both of these are feature film compositing programs that let you use them from your own programs (C++ in case of Shake, Python in case of Toxik I believe). With Photoshop you are probably out of luck since it wasn't really designed with this kind of thing in mind.
Or actually, you might be able to pull it off by running Photoshop and some code to control it in a VM that runs as a background process on your server and then communicating with that from your main server logic via network. That way, only the OS in the VM would have to have a desktop user logged in.
But in either case, Noel is absolutely correct, you'll need to carefully consider any possible licensing issues.
My designer colleagues use PSD’s as their stock format. If these other tools have these features, that would be the first of MANY steps in suggesting moving my colleagues off of Photoshop
- Action Recording
- Metadata (Keywords)
Your VM suggestion is exactly what I have now. I am looking to improve on that. If “script user” could get complete control over the app, that would benefit all script developers, whether they are developing interactive scripts or hands-off scripts. Even an interactive script developer wants only their own dialog boxes to show up, not Photoshop’s.
I mean, it would be hard to convince someone to consider increasing their productivity with scripting if this caveat is always hanging around. “Just package all of those steps in your workflow into a script, launch it and walk away—except you might come back to find it stalled on an error pop-up.”
Message was edited by: skinitpete - first paragraph was incomplete when posted.
Those visual effects tools work non-destructively by default. Pretty much all of them are node-based (with the exception of After Effects), i.e. the user strings together nodes into a process tree, which means you can easily apply the exact same processing steps to other source files. That way you wouldn't need action recording, the file itself is basically an action. However, the graphic design toolset (like text and vector graphics) is usually rather limited, and there is no CMYK support, so unfortunately it probably wouldn't work for your problem.
This is an educated guess, but the trouble seems to be, to implement a complete silent mode, the developers would most likely have to read through the entire Photoshop source code (which must be a lot) and then make changes in almost every single place that interacts with the user in some way, then do excessive testing to make sure they didn't miss anything, then fix all bugs that were caused by those changes, then test again and so on. Photoshop has grown for many years from a very simple program whose initial purpose was to display images on screen. I doubt that anyone back then made any effort to separate the underlying application logic from the user interface. As a consequence, as far as I can tell, when scripting and actions were added, they were basically implemented by more or less simulating user input. And since there aren't many cases where complete silent operation would really be needed (and running Photoshop on a server most likely isn't even covered by the EULA), that decision does make sense.
If the tasks you are trying to automate are very limited (like watermarking, cropping to a certain size etc.), there might be other ways to do it without reling on Photoshop, but if you need the full toolset, I guess you'll be stuck with your current solution for some time.
Those visual effects tools...
A process tree model is ideal, but without the CMYK, it is a no-go.
This is an educated guess, but the trouble seems to be...
I would agree your portrayal of the software engineering challenges except for one thing. SInce Photoshop is a cross-platform product, I am guessing that they WOULD have taken the effort to separate the user interface, since this would ease parallel development of the Mac and PC versions. My guess (and I have been hoping someone from Adobe would jump into this thread and comment on our guesses) is that the scripting does not talk to the UI layer. I think it talks to the application logic, but that the application logic replies in certain cases only to the UI layer.
I mean, they publish ExtendScript Toolkit, scripting guides, SDKs, etc, to support the scripting community. My opinion is that the pieces are there under the hood, but need tightening up.
If the tasks you are trying to automate are very limited...
They are not. We need the full toolset. The workpieces have raster, type, Smart Objects, VSOs. InDesign and Illustrator are not options, and this is for print, so CMYK is a must.
If no one chimes in from Adobe in the next week, I will mark you and Noel as "Answered". I ought to post this over on the ExtendScript side and also chase this up to Adobe's support channel. I will also get clarification on the EULA issue there.
Thanks for your response.
I'm very much willing to be corrected by someone with inside knowledge and I may be completely off here, but I think a big part of the cross-platform aspect of Photoshop is to a large extent still handled simply by having duplicate code for interface elements like dialog boxes for each platform and things like that. The newer parts seem to be different, but especially the older portions of the code and many of the filters still seem to contain a lot of that (just look at the Displace effect). Maintainig a codebase that has historically grown and been subjected to tight deadlines countless times is a bigger challenge than most people realize.
Reading between the lines of what Adobe has communicated over the last years would indicate that they initially set out to really modernize everything during the Cocoa transition (which was planned to span several release cycles), to do a clean separation between the internals and the interface and to create a cross-platform widget toolkit abstraction layer (at some point, I think they considered to transition to the interface toolkit used in the digital video applications like After Effects and Premiere), but basically, halfway into the process, Apple changed course with the discontinuation of 64-Bit Carbon and thus left Adobe in the cold. Lack of a 64-Bit version for OS X had been generating a significant amount of bad press at that point, too (largely based on misinformed assumptions of what magic and amazing things 64-Bit would offer). The Photoshop engineering team then attempted the impossible and initially tried to implement all the modernizations in one cycle, but halfway through they realized there was no way they were going to make it and decided to go with more or less a direct port of the old Carbon code to Cocoa for the time being. If they hadn't done that, there would have been no Photoshop CS5.
The introduction of the unified panel docking system in CS3 (they are referring to it as "Adobe OWL" I think) and later the application frame was the first step of many towards modernizing the entire interface code and unifying the UI of all the suite applications (before, each application had its own separate implementation of the panel system, and suddenly owning a bunch of former Macromedia products probably didn't improve that situation either). The new dark interface and the new panel-based filters in CS6 seems to be their next logical step. Right now each application appears to still be using its own toolkit for dialog boxes and such, some of them possibly even a lot more than one, and some seem to even use the OS APIs directly (I'm not sure I really want to know all the gory details). Then there is ScriptUI, way too many of those awful Flash/Flex dialog boxes/panels and apparently even the toolbar in the Flash IDE itself, toolkits used by shared libraries that are used in more than one application, the installer and licensing system (I think those are using HTML/WebKit for some reason), then plug-ins and so on. I think someone on the internet once made a list with all the different types of sliders in Photoshop's UI, and there were quite a few of them.
I'm sure the folks at Adobe are doing their very best to modernize and unify all the applications within the constraints of the resources they can afford to dedicate to that kind of task, but I imagine it is quite hard to sell upgrades and pay the bills by telling users "brand new version: nothing new, but now using much more elegant code to do exactly the same thing as before, and you only had to wait six years, and we only killed five engineers in the process! buy now!".