5 ms·

The only thing I miss in Photoshop is a command line (Autocad style). This would be a killer feature. I hate looking for a command in the menus or remember a s

The only thing I miss in Photoshop is a command line (Autocad style). This would be a killer feature. I hate looking for a command in the menus or remember a shortcut, I would prefer to remember an alias derived from the name (like Autocad). This (and probably a huge reduction in price) is the only way to make me change to something else.

brudgers 12y ago
AutoCad began with the architectural premise that user interaction would be primarily via a terminal. It was built with the ability to run headless. It was built with the ability to run in batch mode. Like Unix, it was built on a set of single purpose tools. These tools formed the API and the user interacted directly with it in the form of commands. The graphic display was a side-effect. Events on the graphic display were mapped back to the API, i.e. mapped back to commands. The reason, most likely, is that in the days of MSDOS AutoDesk had to write hardware drivers themselves or convince third party hardware vendors write them. Having a developer friendly architecture helped in both cases. Post-Macintosh programs such as PhotoShop went down a different architectural path. There was a pre-existing graphics subsystem and no obvious interest in developing up from the terminal. So these applications were developed down from the GUI. In the days of 256k RAM and 10meg disks, there was a lot of need for expediency and GUI code and application code often mixed. The result was a lack of an AutoCad style API. If a procedure looks at screen layout directly, how do you turn it into a command from the keyboard with sensible parameters? Such a refactoring is hard, messy, and not at on the feature list marketing has developed. Lets face it, the PhotoShop user community would not just reject a command based interface, it might express outrage. Going one step further, in the early 1990's AutoDesk massively refactored AutoCad's code. They took the hit in the form of R13. Then they started adding incredible features with each version again for the next twenty years.
- fat0wl 12y ago
  i understand your point about history but disagree with your conclusion... at this point its not like Adobe would have to re-architect the system cuz im sure when you click & use a tool it is not going "uhhh photoshop system, man, could you like look into this screen & blur stuff" it is calling a well-defined method with an x/y param. They just need to alias those methods from a simple command shell
  - brudgers 12y ago
    Alan Kay talks about a text justification bug in MicroSoft Word that's been around for 30 years. [1] PhotoShop is many many millions of lines of code, making an API that covers all of it is unlikely, and at best it is practical to make some subset of its procedures available from a command line. In contrast, an AutoCad drawing is serializable to a text file of AutoCad commands. At the core of the software architecture, it's analogous to REST versus SOAP soaked in kerosene with three decades of software evolution piled on top. Nobody loves AutoCad's DXF with deep abiding passion, but nobody would take "DXF is not my favorite file format" [2] rants in the source code seriously. The point from AutoCad's <Point:> command is the same point that everything else is built on. It's bottom up. So in the end, a full blown command language for Photoshop would need a <Pixel:> command. And everything else, all the way up, would need to rely on calls to <:Pixel>. That's the level of granularity required to implement a command API like AutoCad's. That's the joy of AutoCad's command line. It's programming with a REPL. Photoshop doesn't have one at its core. [1]: https://www.youtube.com/watch?v=ubaX1Smg6pY&= https://www.youtube.com/watch?v=ubaX1Smg6pY&= [2]: https://code.google.com/p/xee/source/browse/XeePhotoshopLoader.m?r=f16763d221dfca6253983824b470adf553a19e06 https://code.google.com/p/xee/source/browse/XeePhotoshopLoad...
  - richardjdare 12y ago
    Photoshop does have a Javascript scripting system and IDE (ExtendScript Toolkit) that exposes many of its features. Unfortunately its pretty slow and clunky, and it doesn't let you draw programmatically or anything like that. I used it to create a texture/sprite atlas maker for game development[1], and to do batch image composition for animation frames in my last game project[2]. I tried to use it to create animated image processing effects, but I ended up having to use Processing, after reimplementing a bunch of Photoshop features in Java. [1] http://richardjdare.com/blog/2012/11/atlasmaker-0-7-make-texture-atlases-in-photoshop/ http://richardjdare.com/blog/2012/11/atlasmaker-0-7-make-tex... [2] http://richardjdare.com/blog/2013/03/toxin-advanced-sprite-techniques/ http://richardjdare.com/blog/2013/03/toxin-advanced-sprite-t...
- pyre 12y ago
  > If a procedure looks at screen layout directly, how do you turn it into a command from the keyboard with sensible parameters? Such a refactoring is hard, messy, and not at on the feature list marketing has developed. It doesn't seem like one would need to refactor to do something like: $ filter layer1 blur With things like lossless editing, Photoshop has to maintain state somewhere to be able to apply all of the layers to get the image. I get that you might not be able to say do something like: $ selection x1 y1 x2 y2 > Lets face it, the PhotoShop user community would not just reject a command based interface, it might express outrage.
  - brudgers 12y ago
    It seems to me that some of the issues are in the nature of the data. It's a bitmap (or several). The amount of state is equal to the number of pixels. A 1024 x 1024 bitmap has 2^20 bits of state. Though we can usually compress the representation of that state, what we don't have is a high level semantics for describing it. We don't have a language for chunking bitmaps that works independent of a specific context. We can make a DSL for describing GUI elements. It won't work for photographs. Outside of a few specific domains, we don't have a handle into content. We can't write programs for bitmaps that manipulate babies and cars and pop-up menus easily. If we deal with the bitmap as a whole, then it's trivial to write a command that transforms the bitmap as a whole. But without facial recognition style recognition for everything we're stuck dealing with pixels a lot of the time.
    - pyre 12y ago
      I imagine that there are a lot of operations that could benefit from a shell-like interface, even if there are certain operations that don't lend themselves to the paradigm. Even just being able to say something like "Create a circular selection 'box' with a radius of 50px" that you can then manually manipulate with the mouse could be useful. More useful than trying to create the same thing via just mouse input.
      - brudgers 12y ago
        I don't disagree. My view comes from having switched away from AutoCad about seven years ago to a Cad package originally developed for the Mac. I ranted about the ways in which it's API sucked compared to AutoCad to the point of being banned from the bulletin board...in those days I enjoyed trolling more than today. Munging the application logic and the display does have some advantages, and there are some aspects of the work-flow provided by the not-Autocad software that are really useful for producing drawings...Solid filling rectangles is not a geometric idea but it allows for placing the rectangle in the foreground of an image. But unlike AutoCad keyboard entry is always a second class citizen and there's no way not to use the mouse in the middle of trying to complete just about every interaction. Indeed one of my big rants was about some distinction between tools and commands where binding a command to an icon required an extra click in the drawing area in order to run. There's no reason that a circular selection box couldn't be moved with "$> move 129 -204". Indeed if you're working pixel by pixel, that's exactly the way to get exactly what you mean. Exacting layouts are exacting because we hold that level of detail in our heads.
- jacquesm 12y ago
  You're actually giving an absolutely amazing path on how one could conceivably develop a real photoshop competitor by doing to pixels what autocad did for cad: to start off from a programmable base. Something along the lines of emacs meets pixels.
  - richardjdare 12y ago
    I am currently working on the prototype of such an application :) I had a similar idea after getting frustrated with Photoshop scripting for my last game project[1]. I'm not ready to show anything yet though, very early days... [1]http://richardjdare.com/blog/2013/02/the-next-photoshop/ http://richardjdare.com/blog/2013/02/the-next-photoshop/
    - slacka 12y ago
      I like the idea of your PhotoShopNext, but the video at the bottom has been marked private. Also Antigen looks like a fun game. Any plans for an android port?
      - richardjdare 12y ago
        The youtube vid was an old demonstration of Ivan Sutherland's Sketchpad software. I will try and find another version. I'm not sure if there will be an android port of Antigen. The mobile gaming scene is not very conducive to indie devs at the moment:) I also didn't write it in a very cross-platform manner. I won't make that mistake again.
  - brudgers 12y ago
    AutoCad sells for many thousands of dollars a seat as do its commercial competitors. There is no passable open source alternative for professional work in many industries particularly AEC. AutoDesk's business model is based on selling products that are used to manually translate requirements tossed over the transom into designs. The developer of a $50,000,000 project is going to pay several million dollars in design fees. There's a lot of value proposition in an easy button. However a lot of domain knowledge is necessary to produce something reliable. Either way - developing a product to compete with PhotoShop or AutoCad - is a big dollar proposition. There's more capital investment that winds up requiring AutoCad than PhotoShop. A lot of what PhotoShop does is a nice-to-have. Building departments require building plans. Paving contractors require road plans. A billion dollars in those industries isn't even news.
- vidarh 12y ago
  > In the days of 256k RAM and 10meg disks, there was a lot of need for expediency and GUI code and application code often mixed. The result was a lack of an AutoCad style API. You may be right that this is how it happened, but there's not really any reason for it to have happened that way. E.g. on the Amiga, which had similar hardware constraints to that, a lot of apps did work similarly to the way you describe AutoCad: everything internally mapped to commands, and the commands operated on the data model and updated the view, and while they were not designed to run headless, they were often designed from the beginning for everything to be scriptable. This was done because everyone expected the API - from about AmigaOS 2.0 onward, if you didn't have an AREXX API it'd be commented on negatively in reviews etc. I think the difference is the lack of a culture for scripting. Even with AppleScript, there's not the same culture for scripting in the Mac world. Even less so in the Windows world (outside of developers). Unix users expect scripting and components designed for it. Amiga users expected scripting of gui apps too.
  - brudgers 12y ago
    The first computer I owned was an A500. In a box somewhere, I think there are all four of the 1.1 Rom Kernel Manuals...the ones sold in bookstores even after Amiga OS2.0 was well established. Amiga OS was strongly influenced by Unix. That's what allowed all those ports of Unix commands to fill the FredFish disks. In a sense the Amiga was what a company needed to do when buying a Super Bowl launch ad spot isn't on the table. The Amiga 1000 was beautifully engineered but aesthetics were low enough on the priority list that the sidecar made it to market. One could make a case that all that Rexx integration was a waste of effort: The Amiga died for just about everyone but a few hardcores and software like Photoshop lives on. The ball of mud is the most successful software architecture by volume.
fenomas 12y ago
Not what you're looking for, but as a point of interest Photoshop actually has accumulated several layers of internal scripting over the years. The newest and coolest is an embedded Node.js server - you can pull in arbitrary node modules and run them in a context where various PS-related APIs are exposed. The drawbacks are: 1. Not all features have nice interfaces. For some things you need to go through this ancient, hairy API based on tons of (sparsely documented) magic strings. 2. Most of the APIs are made to support the UI, so it can be hard or easy to do things depending on how the UI works. For things involving settings dialogs, or anything that's a multistep process in the UI, it can be pretty nontrivial.
liber8 12y ago
This is one thing I love about macs. Click help, type in the first word of the command, and it will highlight where that command is in the menu. No more hunting or trying to remember seldom-used shortcuts. Apple has had this feature for years and years. I still can't believe Microsoft hasn't copied it (or perhaps it has with 8? I'm still using 7 on my main editing machine.) I will often fire up PS on my Macbook just to use the search to find a command, rather than poking around the menus for it on my main machine.

brudgers 12y ago

AutoCad began with the architectural premise that user interaction would be primarily via a terminal. It was built with the ability to run headless. It was built with the ability to run in batch mode. Like Unix, it was built on a set of single purpose tools. These tools formed the API and the user interacted directly with it in the form of commands. The graphic display was a side-effect. Events on the graphic display were mapped back to the API, i.e. mapped back to commands. The reason, most likely, is that in the days of MSDOS AutoDesk had to write hardware drivers themselves or convince third party hardware vendors write them. Having a developer friendly architecture helped in both cases. Post-Macintosh programs such as PhotoShop went down a different architectural path. There was a pre-existing graphics subsystem and no obvious interest in developing up from the terminal. So these applications were developed down from the GUI. In the days of 256k RAM and 10meg disks, there was a lot of need for expediency and GUI code and application code often mixed. The result was a lack of an AutoCad style API. If a procedure looks at screen layout directly, how do you turn it into a command from the keyboard with sensible parameters? Such a refactoring is hard, messy, and not at on the feature list marketing has developed. Lets face it, the PhotoShop user community would not just reject a command based interface, it might express outrage. Going one step further, in the early 1990's AutoDesk massively refactored AutoCad's code. They took the hit in the form of R13. Then they started adding incredible features with each version again for the next twenty years.

fat0wl 12y ago
i understand your point about history but disagree with your conclusion... at this point its not like Adobe would have to re-architect the system cuz im sure when you click & use a tool it is not going "uhhh photoshop system, man, could you like look into this screen & blur stuff" it is calling a well-defined method with an x/y param. They just need to alias those methods from a simple command shell
- brudgers 12y ago
  Alan Kay talks about a text justification bug in MicroSoft Word that's been around for 30 years. [1] PhotoShop is many many millions of lines of code, making an API that covers all of it is unlikely, and at best it is practical to make some subset of its procedures available from a command line. In contrast, an AutoCad drawing is serializable to a text file of AutoCad commands. At the core of the software architecture, it's analogous to REST versus SOAP soaked in kerosene with three decades of software evolution piled on top. Nobody loves AutoCad's DXF with deep abiding passion, but nobody would take "DXF is not my favorite file format" [2] rants in the source code seriously. The point from AutoCad's <Point:> command is the same point that everything else is built on. It's bottom up. So in the end, a full blown command language for Photoshop would need a <Pixel:> command. And everything else, all the way up, would need to rely on calls to <:Pixel>. That's the level of granularity required to implement a command API like AutoCad's. That's the joy of AutoCad's command line. It's programming with a REPL. Photoshop doesn't have one at its core. [1]: https://www.youtube.com/watch?v=ubaX1Smg6pY&= https://www.youtube.com/watch?v=ubaX1Smg6pY&= [2]: https://code.google.com/p/xee/source/browse/XeePhotoshopLoader.m?r=f16763d221dfca6253983824b470adf553a19e06 https://code.google.com/p/xee/source/browse/XeePhotoshopLoad...
- richardjdare 12y ago
  Photoshop does have a Javascript scripting system and IDE (ExtendScript Toolkit) that exposes many of its features. Unfortunately its pretty slow and clunky, and it doesn't let you draw programmatically or anything like that. I used it to create a texture/sprite atlas maker for game development[1], and to do batch image composition for animation frames in my last game project[2]. I tried to use it to create animated image processing effects, but I ended up having to use Processing, after reimplementing a bunch of Photoshop features in Java. [1] http://richardjdare.com/blog/2012/11/atlasmaker-0-7-make-texture-atlases-in-photoshop/ http://richardjdare.com/blog/2012/11/atlasmaker-0-7-make-tex... [2] http://richardjdare.com/blog/2013/03/toxin-advanced-sprite-techniques/ http://richardjdare.com/blog/2013/03/toxin-advanced-sprite-t...
pyre 12y ago
> If a procedure looks at screen layout directly, how do you turn it into a command from the keyboard with sensible parameters? Such a refactoring is hard, messy, and not at on the feature list marketing has developed. It doesn't seem like one would need to refactor to do something like: $ filter layer1 blur With things like lossless editing, Photoshop has to maintain state somewhere to be able to apply all of the layers to get the image. I get that you might not be able to say do something like: $ selection x1 y1 x2 y2 > Lets face it, the PhotoShop user community would not just reject a command based interface, it might express outrage.
- brudgers 12y ago
  It seems to me that some of the issues are in the nature of the data. It's a bitmap (or several). The amount of state is equal to the number of pixels. A 1024 x 1024 bitmap has 2^20 bits of state. Though we can usually compress the representation of that state, what we don't have is a high level semantics for describing it. We don't have a language for chunking bitmaps that works independent of a specific context. We can make a DSL for describing GUI elements. It won't work for photographs. Outside of a few specific domains, we don't have a handle into content. We can't write programs for bitmaps that manipulate babies and cars and pop-up menus easily. If we deal with the bitmap as a whole, then it's trivial to write a command that transforms the bitmap as a whole. But without facial recognition style recognition for everything we're stuck dealing with pixels a lot of the time.
  - pyre 12y ago
    I imagine that there are a lot of operations that could benefit from a shell-like interface, even if there are certain operations that don't lend themselves to the paradigm. Even just being able to say something like "Create a circular selection 'box' with a radius of 50px" that you can then manually manipulate with the mouse could be useful. More useful than trying to create the same thing via just mouse input.
    - brudgers 12y ago
      I don't disagree. My view comes from having switched away from AutoCad about seven years ago to a Cad package originally developed for the Mac. I ranted about the ways in which it's API sucked compared to AutoCad to the point of being banned from the bulletin board...in those days I enjoyed trolling more than today. Munging the application logic and the display does have some advantages, and there are some aspects of the work-flow provided by the not-Autocad software that are really useful for producing drawings...Solid filling rectangles is not a geometric idea but it allows for placing the rectangle in the foreground of an image. But unlike AutoCad keyboard entry is always a second class citizen and there's no way not to use the mouse in the middle of trying to complete just about every interaction. Indeed one of my big rants was about some distinction between tools and commands where binding a command to an icon required an extra click in the drawing area in order to run. There's no reason that a circular selection box couldn't be moved with "$> move 129 -204". Indeed if you're working pixel by pixel, that's exactly the way to get exactly what you mean. Exacting layouts are exacting because we hold that level of detail in our heads.
jacquesm 12y ago
You're actually giving an absolutely amazing path on how one could conceivably develop a real photoshop competitor by doing to pixels what autocad did for cad: to start off from a programmable base. Something along the lines of emacs meets pixels.
- richardjdare 12y ago
  I am currently working on the prototype of such an application :) I had a similar idea after getting frustrated with Photoshop scripting for my last game project[1]. I'm not ready to show anything yet though, very early days... [1]http://richardjdare.com/blog/2013/02/the-next-photoshop/ http://richardjdare.com/blog/2013/02/the-next-photoshop/
  - slacka 12y ago
    I like the idea of your PhotoShopNext, but the video at the bottom has been marked private. Also Antigen looks like a fun game. Any plans for an android port?
    - richardjdare 12y ago
      The youtube vid was an old demonstration of Ivan Sutherland's Sketchpad software. I will try and find another version. I'm not sure if there will be an android port of Antigen. The mobile gaming scene is not very conducive to indie devs at the moment:) I also didn't write it in a very cross-platform manner. I won't make that mistake again.
- brudgers 12y ago
  AutoCad sells for many thousands of dollars a seat as do its commercial competitors. There is no passable open source alternative for professional work in many industries particularly AEC. AutoDesk's business model is based on selling products that are used to manually translate requirements tossed over the transom into designs. The developer of a $50,000,000 project is going to pay several million dollars in design fees. There's a lot of value proposition in an easy button. However a lot of domain knowledge is necessary to produce something reliable. Either way - developing a product to compete with PhotoShop or AutoCad - is a big dollar proposition. There's more capital investment that winds up requiring AutoCad than PhotoShop. A lot of what PhotoShop does is a nice-to-have. Building departments require building plans. Paving contractors require road plans. A billion dollars in those industries isn't even news.
vidarh 12y ago
> In the days of 256k RAM and 10meg disks, there was a lot of need for expediency and GUI code and application code often mixed. The result was a lack of an AutoCad style API. You may be right that this is how it happened, but there's not really any reason for it to have happened that way. E.g. on the Amiga, which had similar hardware constraints to that, a lot of apps did work similarly to the way you describe AutoCad: everything internally mapped to commands, and the commands operated on the data model and updated the view, and while they were not designed to run headless, they were often designed from the beginning for everything to be scriptable. This was done because everyone expected the API - from about AmigaOS 2.0 onward, if you didn't have an AREXX API it'd be commented on negatively in reviews etc. I think the difference is the lack of a culture for scripting. Even with AppleScript, there's not the same culture for scripting in the Mac world. Even less so in the Windows world (outside of developers). Unix users expect scripting and components designed for it. Amiga users expected scripting of gui apps too.
- brudgers 12y ago
  The first computer I owned was an A500. In a box somewhere, I think there are all four of the 1.1 Rom Kernel Manuals...the ones sold in bookstores even after Amiga OS2.0 was well established. Amiga OS was strongly influenced by Unix. That's what allowed all those ports of Unix commands to fill the FredFish disks. In a sense the Amiga was what a company needed to do when buying a Super Bowl launch ad spot isn't on the table. The Amiga 1000 was beautifully engineered but aesthetics were low enough on the priority list that the sidecar made it to market. One could make a case that all that Rexx integration was a waste of effort: The Amiga died for just about everyone but a few hardcores and software like Photoshop lives on. The ball of mud is the most successful software architecture by volume.

fenomas 12y ago

Not what you're looking for, but as a point of interest Photoshop actually has accumulated several layers of internal scripting over the years. The newest and coolest is an embedded Node.js server - you can pull in arbitrary node modules and run them in a context where various PS-related APIs are exposed. The drawbacks are: 1. Not all features have nice interfaces. For some things you need to go through this ancient, hairy API based on tons of (sparsely documented) magic strings. 2. Most of the APIs are made to support the UI, so it can be hard or easy to do things depending on how the UI works. For things involving settings dialogs, or anything that's a multistep process in the UI, it can be pretty nontrivial.

liber8 12y ago

This is one thing I love about macs. Click help, type in the first word of the command, and it will highlight where that command is in the menu. No more hunting or trying to remember seldom-used shortcuts. Apple has had this feature for years and years. I still can't believe Microsoft hasn't copied it (or perhaps it has with 8? I'm still using 7 on my main editing machine.) I will often fire up PS on my Macbook just to use the search to find a command, rather than poking around the menus for it on my main machine.