Hi folks, I wanted to offer some comments about the macro discussion.
While I would agree that macros are not a single solution to a problem, they can be a real convenience and what I feel is more important, have a positive contribution to the quality of the work. If for example, you use a macro to create a layer, and assign it's name and position in the layer stack, then the name and position are reliable (no misspellings / forgot to name it) if you are going to access that layer with another macro. I actually find that associating a set of commands with the 'state' of the editing process makes the difference between a 'macro' that I use occasionally verses a 'step' that I use for ever image that I process with Gimp. There are a couple of advantages to associating a 'step' with the sate of the editing process: You can apply the 'step' to many images at a time instead of one at a time. (for each image in the directory - bump it to the next step) You don't have to keep track of the order in which you apply steps, in the case of a macro, if it wants to access of use a layer that hasn't been created yet the results can be counterproductive. As a user, the types of things that I do with 'steps' are the preparation work for something that I would do by hand and they are the things that I would do on every image (in a particular order). As an example, the first - by hand - operation that I am going to do is see if I need to use the rotate, transform or crop tool. My personal workflow is to do these operations before I create any new layers. The automated preparation work is: 1st Step Set the grid spacing to be 24 squares (based on long side) and centered on the image Expand the canvas by 25% (of long side) Rename the 1st and only layer "Original" Following this example, the next step would be to get the image ready for using the 'curves' tool. 2nd Step Shrink the canvas to fit the layer "Original" Set the grid spacing - one grid = image perimeter, essentially turning grid off Extract the Color information from "Original" to a new layer "ColorLayer" & push it to bottom of layer stack Create a copy of "Original", name it "DynRange" & push it to the top of the layer stack The sets of commands whether they are macros or steps aren't the big decisions, but being able to package all of the little decisions and apply them to several (whether it is 2 or 3 - 20 or 30) has a dramatic impact on the time that it takes to edit the images, produces consistent results, and does not negatively impact the part of the process where creativity or human judgment is desired. Of course there is no one workflow that will be the right one for every one, or even a modest percentage of the people who use Gimp, but if it is fairly easy to record steps and associate those steps with the state of a workflow that an individual wants to set up, it can be a real nice thing. I don't know where the development team would want to draw the line how much to provide, but it seems that good set of tools for people to customize their own workflow would be a good goal. Stephen Kiel On Fri, Mar 21, 2014 at 1:33 PM, peter sikking <pe...@mmiworks.net> wrote: > hi all, > > Joao asked me personally to comment here, so here I am. > > I will do some horrible top-posting because I think > I can summarise quite a bit what you wrote. > > I believe what you refer to below are 'macros.' > > simple enough: at any point in GIMP where an operation > can be applied, a macro can also be applied. > > I intent to help GIMP users to make/edit macros in many ways: > record them; grab a bunch of operations from the operations > stack and put a name on it; write some source text in a file. > > do keep in mind that macros are nothing but a convenience > for some GIMP users, not all GIMP users. a macro is never > the single solution to a problem. > > first working with operations (see > <http://blog.mmiworks.net/2012/01/gimp-full-gegl-ahead.html> > for an old sketch, will be updated at lgm) has to work in > a sufficient fashion before we can think of introducing macros. > > ps: first we would have to start supporting 'export pipelines' > where users can define a series of operations for each pipeline, > and save these to be used in different xcf files, before macros > could be used in these pipelines. > > users should not have to learn macros to make use of these > pipelines (a macro is never the single solution to a problem). > > > Hi, > > I would like to discuss about the possibility > > of a "Set of operations" GIMP item - > > > > In the current state of GIMP, I think one > > nice thing to have would be the ability to > > specify sets of GEGL operations that could > > be re-used across the UI in some different places. > > > > One example of such "Set of operations" could be, > > for example, a gaussian blur filter - the set > > includes the parameters as well. Another > > example could be a "Resample to 50% size, Unsharp mask" > > set. > > > > Where could those be used? > > I thought of primarily two places - with more potential > > nice places to come along: > > > > 1. As an "adjust layer" - just that - have > > a special Layer class that encapsulates a set > > of Gegl operations, and apply then to the > > rendering of the layer imediatelly bellow. > > This would give us "Adjustment layers" > > as they are called in other software, > > essentialy "for free" > > > > 2. Attached to an image, as a set to be > > automatically applied before exporting the > > image to an specific format. > > Currently, the "merge-visible-layers" action > > is performed at this stage, for most formats. > > But in some mail-threads here it became clear that > > the ability to resize an image to an specific > > size, among other things, could greatly > > simplify the current workflow for keeping > > a high-quality XCF image, and exporting > > incremental versions of down-sampled/filtered > > versions for production. (Like in edit, save, > > resize to 50%, export as PNG - undo to further > > editing the image, and the resize is lost, and must > > be reapplied when exporting the new version) > > > > And there could be some "bonus places" to attach these > > "sets of operations": > > 3. To patterns, before applying them - so > > that rotation and scaling of patterns would > > be easy > > 4. To brush masks, as part of the painting dynamics. > > > > > > Can we discuss this further along? > > I know Mitch is experimenting with > > operations attached to layers, but I don't > > know wether they are along thse lines, or more > > like recording all operations mad in a layer, > > in an early quest to "non destructive editting". > > > > Maybe there is a roadmap for a similar > > thing already, that I am not aware of - but > > having the "sets of operations" behave > > as regular GIMP items that can be used - and > > being able to pick/create then at the layers dialog > > bucket fill tool options, export dialogs, could > > be a nice way of enabling the possibilities > > of GEGL and non-destructive editing to end users. > > > > --ps > > founder + principal interaction architect > man + machine interface works > > http://blog.mmiworks.net: on interaction architecture > > > > _______________________________________________ > gimp-developer-list mailing list > List address: gimp-developer-list@gnome.org > List membership: > https://mail.gnome.org/mailman/listinfo/gimp-developer-list > List archives: https://mail.gnome.org/archives/gimp-developer-list > -- Stephen Kiel 26602 Strafford Mission Viejo, CA 92692 *Mobile/SMS (949) 702-1993* Home (949) 367-2915 snick.k...@gmail.com http://stephenkiel.blogspot.com/ _______________________________________________ gimp-developer-list mailing list List address: gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
