"Joao S. O. Bueno Calligaris" <[EMAIL PROTECTED]> writes:
> 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.
The different process could become a problem but it isn't necessarily
one. The problem is that such a framework needs to be well-defined and
needs a lot of effort to setup. A whole lot of more effort than it
would be to help a dozen newbies to understand how to do such things
in the core. After that has happened, after a few more paint methods
have been established in the core, we should have gathered enough
experience to get paint-core nodes done right in GEGL. At that point
(when GEGL nodes are being used for drawing) one could also consider
to allow such nodes to be written in other languages such as Python.
> 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.
Let's see. If I argue that it would be too much hazzle to add a
plug-in framework, the alternative solution you come up with is to
integrate a text file parser that compiles a procedural brush on the
fly? Are you joking or can't you see yourself that this is an order of
magnitude more complex and still a lot less flexible than the initial
Gimp-developer mailing list