I managed to get this patch to build with trunk yesterday, after some struggling. I am only starting to understand what is going on here, but I thought it might be useful to dash off a thumbnail review. First, for readers who might not examine the patch in detail, it is worth saying that this is a significant effort, representing several months of work, and a design that has been thought out with a lot of care. It is by no means a finished product, but it is already very impressive. The general concept is to create something like a "pluggable brush". The code sets up a "custom paintbrush tool", with a customizable paint core. (The paint core is the set of C functions that render brushmarks on the image.) The paint core is customized by registering a set of "paint core modifiers". Each "modifier" inserts a gui-block into the tool options, and includes C code for modifying the brush in some way. When the user paints, all of the modifiers are applied in sequence before the mark is finally made on the image. In the patch, three modifiers are included: a "brush modifer", a "blend modifier", and a "smooth modifier". The code for these is at present added to app/paint, but the idea is eventually to make it possible to add modifiers as "modules". In Gimp, and other programs that use Glib, *modules* are program-fragments that can be compiled separately from the main application, and linked in dynamically while the program is running. They differ from plug-ins in that once loaded they function as part of the application, not as separate programs that communicate with the application. The danger of modules is that if they crash, the whole program crashes with them. The power is that they have complete access to everything that Gimp can do. Currently Gimp does not use modules very heavily: they show up mainly as color selectors, display filters, and handlers for exotic types of input. Adding modules to Gimp is easy in principle: you just place them in the "modules" folder in your Gimp directory. There are very few Gimp developers who have actually written a module, though, and it isn't clear to me whether it is intrinsically more difficult than writing a plug-in, or whether it simply lacks a good set of instructions and a good "template". It's pretty clear that this code will not be ready for 2.6, which is on a fast development track. In any case, the code looks very promising, and I would favor getting the development process into SVN as soon as possible, perhaps in a special branch dedicated for the purpose. -- Bill _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
