The next user interface for Phatch

Registered by Stani on 2009-06-16

The idea is from the moment qt and pil are py3 ready to switch to qt+webkit+jQuery. It would feature wo modes for phatch: as server and as desktop app. Desktop app is still needed for eg selecting multiple files. For the desktop app the qt code should be reduced to the absolute minimum: only the chrome and os dialogs. It should be easy to do a gtk version later as well, as that code should not be that much. Or even cocoa on the mac, but we'll focus on qt first.

Reference applications:
- automator
- naked light (http://www.naked.la/light/features/node_based_compositing/)

Phatch is a workflow designer, not a recorder as:
- http://www.sandklef.com/xnee/

Blueprint information

Status:
Not started
Approver:
Stani
Priority:
High
Drafter:
Stani
Direction:
Approved
Assignee:
Stani
Definition:
Drafting
Series goal:
None
Implementation:
Not started
Milestone target:
None

Related branches

Sprints

Whiteboard

REFERENCES
- http://javascript.neyric.com/wireit/examples/jsBox/jsBox.html

Stani 19-6-2009
About multiple backends, in Phatch 0.2 everything is hidden in one imagemagick action. We have to see how we can mix that with pil actions. Maybe like music players: genre (category), artist (application: PIL, imagemagick), song (action) and you can make your playlists. The cover art is the preview. The UI should only show actions which make sense in the current context (eg no text operations on images)

Juho 22-6-2009
Should images be treated as actions? Currently images fed to the action list are selected using specific user interface. Treating images as actions would make it possible to handle certain actions, such as background and watermark, implicitly. A couple of examples of what you could do with a system such as this (note that I have mangled the action functionality a bit from the current):
Canvas (defines canvas dimensions) -> Gradient (chosen gradient + location. composited on canvas) -> Image (location + other properties as needed. composited on top of gradient on top of canvas) -> ... -> Save (sink, it should be possible to place these in the middle too if so desired)

Read "->" as composite/mix operation. It should be possible to determine which blending mode to use at those controls.

Another example (doable in the current system too after Background action is patched up a bit):
Proposed system:
Canvas -> Image (contains Tile modifier) -> Text -> Save

Current system:
Background -> Text -> Save
Note that the "Canvas" has to be hacked in this by providing it a blank image with desired dimensions.

In proposed system image contains a ~modifier~. In this case it makes image to be treated as if it was tiled. Another possible modifier would be flip (flips image on either x or y axis). It might be interesting to have modifiers for colors too (ie. to grayscale, solarize, mask?, whatever). By default modifiers are atomic which means they are easy to attach/remove as needed and won't take much space from the user interface. In my view they cut down the complexity of action lists as you get another level of abstraction (ie. general view of the composite + specific view of given image). Note that modifiers should work at least with text actions too.

Note that UI wise the modifiers could exist within actions (ie. suppose regular actions are laid out vertically, modifiers could take some horizontal space within these actions). At simplest they could be shown as icons. On click/hover the exact properties could be shown.

I'm probably looking this from more compositing point of view than batching but I don't see why ideas proposed above would conflict with the current system. I see it more of an extension. Probably the main thing is the separation of an actual image action.

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.

Subscribers

No subscribers.