Hi, "Joao S. O. Bueno Calligaris" <gwidion@xxxxxxxxxx> 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 proposal? Sven
