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
-><-
_______________________________________________
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
