Hi Alexandre, On Jan 25, 2008 9:52 PM, Alexandre Prokoudine <alexandre.prokoudine@xxxxxxxxx> wrote: > On Jan 25, 2008 11:01 AM, Sven Neumann wrote: > > > Actually, I don't think that we need to put action recording on our list > > as that will become obsolete with non-destructive editing. > > This is apples and oranges, Sven :-) Non-destructive editing boosts > productivity as well, but has nothing (or very few things) in common > with *automation*. It does, though. If you make a chunk of graph -- say you want to gaussian-blur a layer, gradient-map some part of it, and posterize the result to 32 levels; you could do this with the following snippet of graph: (graph root) | posterize (levels = 32) | +- atop | | | mask | | | gradient-map (gradient = <how would you specify this?>) | | +-gauss-blur (hblur = 5, vblur = 5) | +-sourcelayer In case that isn't clear: Source layer is gauss blurred, A gradient-mapped version is made, which is then masked. This image is then rendered atop the gaussian-blurred image, and the result is posterized. This is what is conventionally covered by macros, this kind of thing. > All the users who ever bugged you asking for macros > recording did it because they don't feel like programmers to learn > Script/Python/Perl-Fu. With non-destructive editing, used as above, almost all the things that users want to do are things that can be expressed in terms of a modification of the image graph. The example you see above -- the only user input required would be to choose which layer becomes sourcelayer. twould probably be pretty easy to build a 'quick change' dialog where the user can change all the involved values (eg gauss blur radius.) The things which do not fall into that category.. * batch processing (trivial amount of programming. Just keep resetting the filenames at the leaf and root of a graph). * view handling (I'd like to be able to, say, tag an image or directory as 'pixel art', and when I opened one of those images, have an additional, 300% view appear (for real size preview). Personally I think views are one of the things that may end up needing a PDB interface*, despite the vast obsoletion that should otherwise happen (gauss blur, gradient map, colorize, what ever filter you name -- won't need a PDB interface any more, they just implement their gegl Ops) I've just gone through the menus.. and the vast majority of actions available are directly equivalent to inserting, deleting, or shuffling nodes in a graph. The remainder alter either the context (Tools menu, View menu) or the GUI (Dialogs menu, View menu). (We might want to consider implementing a 'meta-load' Op, that would load a graph from file and pass image data through it. That would be a pretty simple and flexible way of facilitating macros shared between images -- just connect the output at a place of the user's choosing.) What significant sequence of actions that you can take is there, that cannot be done by simple graph editing? _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
