Ok, for those who are wondering, this is discussion is tied with what I've requested in [Bug 140165] A Paint Tool that allows stroke events to callback plug-in procedures My initial wriitng in there was: "Hi, I know it had been thought before, but anyway could not find it in bugzilla. So here it comes: GIMP should implement a "Generic Paint Tool" that would not affect the image, but rather provide a callback with each stroke/pointer movement parameters. This would allow plug-ins to implement a lot of functionality currently only available to things implemented directly on the core (therefore clugging the UI)." On the latest post in there, Sven wrote: " Well, "some description files" isn't very descriptive. Nor is "a string of operators". And you could certainly not do anything like Iwarp based on such an infrastructure. Joao, this report is void. It's a loose collection of buzzwords, nothing else. Either you come up with a reasonable description of what you want or we will have to close this report. " What I want here is to build such a reasonable request - bugzilla doesn't serve as a scratch. Willian had shown us that: On Tuesday 23 November 2004 21:15, William Skaggs wrote: >(...) > And now I see that to create my new "spew" tool, I need to do the > following things: > > 1) In app/paint, "cp gimpink.c gimpspew.c" and then edit gimpspew.c > to s/ink/spew/g (don't take this literally). > > 2) Handle gimpink.h similarly. > > 3) in paint/gimp-paint.c, add an include for "gimpspew.h" and add > gimp_spew_register to the register_funcs array. > > 4) in app/tools, copy gimpinktool.c and gimpinktool.h to > gimpspewtool.c and gimpspewtool.h, then change "ink" to "spew" > everywhere in the new files. > > 5) in app/tools, handle gimpinkoptions-gui.c and > gimpinkoptions-gui.h the same way. > > 6) Add the new files to Makefile.am in the appropriate places. > > 7) In tools/gimp-tools.c, add "gimpspewtool.h" as an include, and > add gimp_spew_tool_register to the register_funcs array. (I found > this by sheer luck.) > > 8) (The hard part) Edit paint/gimpspew.[ch] and > tools/gimpspewoptions-gui.c to give the desired new functionality. > The code from gimpink.c is rather complex and will no doubt give > rise to more questions. > > Does that look right? > > No, I see that I haven't created an icon yet. Fortunately I think > I more or less know how to do this: > > 9) Create stock-tool-spew-16.png and stock-tool-spew-22.png and > place them in themes/Default/images/tools. As I understand it, the > appropriate line in libgimpwidgets/gimpstock.h will be > autogenerated if in the themes directory I then do "make -C clean; > make". What I do want is that one doesn't need to recompile the GIMP for playing with paint variations. When I first reported I was thinking of being able to write such callbacks in Python language, so that changes on the paint behavior would not require any compiling at all. Moreover, parameters for a painting tool would be added at will - since python plug-ins can combine the ease of script-fu with the power of C plug-ins. I was pointed that it is technically difficult to write such a callback, since the plug-in runs in a separate process. So the suggestion taht arised is to have a paint tool that reads what it will do from plain text files. These plain text files will be stored in a collection in their own directory, just like script-fus have one, brushes have one. curves have another. Each of these plain text files, which I've called "procedural brush" should provide a way to calculate parameters of painting based on other painting variables. Existing variables I can think of right now are: Image coordinates - relative and absolute, painting speed, stroke angle, pressure, tilt, time of stroke event, stroke length, and paint color - and more date to work is available on the pixels that are already on the drawable. (The smudge tool makes use of them, for example). Such a procedural brush could be able to specify something as trivial as: "the radius of the stroke should vary linearly in the Y direction, being wider at image botton, and 0 at image top." So, a "procedural brush" file describing this could just be something like: out_radius = in_radius * (in_y / in_height); So - it would be something fun to try, and skecth. If one would like to make it wider to the left, instead of to the botton, all taht would be needed would be to change taht line to: out_radius = in_radius * (in_x / in_width); Something obviously with to few serious uses to go into the core as a new tool. But just the other day one guy was asking for somthing just like that in GUG (hewanted the stroke radius to vary with stroke length). The same file could specify more parameters, that would be made available for the user to config, just like script fu - The procedural brush could ask for a color gradient, a fixed radius, an starting angle, a pattern or drawable from were to clone data, and so on. A more complex brush behavior I can think of right now, would be one that'd draw a cycloid curve (a coil) around the cursor position while stroking. The syntax might be something of the type: #required parameters: (user_spacing, numeric, 1, 100); (user_radius, numeric, 0, 1000); out_x = in_x + user_radius + sin (user_spacing * stroke_lenght ); out_y = in_y + user_radius + cos (user_spacing * stroke_lenght ); out_connect_strokes = true; -------- Please note that this syntax is loose for now - but I think this is a better way of expressing what I have thought of. I prefer to get more feedback from the list before going on bugzilla. Also, as I stated earlier, I am in no way urging anyone to implement this for me - I intend to work on it with help of whoever wants to, when the idea matures. Regards, JS -><-
