Hi, "William Skaggs" <weskaggs@xxxxxxxxxxxxxxxxxxx> writes: > Let me give a specific example. I know by this time, having worked with > GIMP for months, that "drawing tools" are tools that make temporary marks > on the image display (as opposed to the image itself), and that all such > drawing is done in XOR mode so that it can be erased by redrawing. But > these very basic facts are not written down anywhere, to the best of > my knowledge. And how could anybody unfamiliar with the GIMP code, > even being a brilliant programmer knowing everything about C, Glib, Gtk+, > etc, make any progress on tool development without understanding them? > To derive them from the GimpDrawTool code is by no means straightforward. If you had a look at the Ink tool you would have noticed that all paint tools are extraordinarily simple. I agree that other tools (those that draw to the display) are a lot more complex but all paint tools are identical except that they register different GimpPaintCore objects. So you don't even need to deal with tools at all (which is admittedly one of the most complex and least cleaned up parts of the Gimp code). All you need to do is to derive a new GimpPaintCore, either directly from GimpPaintCore or (in case you want to make use of brushes) from GimpBrushCore. This is all nicely abstracted in the app/paint folder and you basically don't need to worry about anything outside this directory. All you need to do is to implement a couple of methods. Just take an existing paint core as an example to copy from. > There are two rather obvious difficulties in working in the core. > First, (and less importantly), each change requires recompiling the > main GIMP app, which takes a lot longer than recompiling a plug-in. Huh? You don't need to recompile the whole thing. Of course that would take a lot of time but if you are working on a single C file, that argument is void. > Second, it means either putting highly speculative code into CVS > head or else creating a branch and then facing the challenge of > keeping it consistent with head. That is void as well. A paint core is easy enough to be understood quite easily and since the code is in a single file, there is no risk at all that such problems could arise. > Also, it is my impression that coders are often reluctant to ask what > seems like very basic questions, because they know how much effort you > and Mitch are already putting into GIMP devlopment, and know that basic > questions are often the kind that take the most effort to answer. Well, that is, please excuse me, very stupid. We aren't putting our free time into cleaning up the code for ourselves only. We would love to see more people working on the core and I would very much appreciate if you could stop spreading this FUD that hacking the core would be something that only experts could consider to do. > In my opinion, anyway, the most useful thing you (and Mitch) could > do, in terms of encouraging this type of development, would be to > write a tutorial showing the steps involved in creating a new > painting tool, and explaining the reason for each step. There are a couple of paint tools in the core. I don't see how we could document this any better than by example. I've offered a helping hand for anyone who wants to work on new paint tools but I am certainly not going to waste the very few free time that I have by writing tutorials. Sven
