> 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.
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.
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.
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.
It doesn't seem like one would need to refactor to do something like:
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: > Lets face it, the PhotoShop user community would not just reject a command based interface, it might express outrage.