"William Skaggs" <[EMAIL PROTECTED]> 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.

Gimp-developer mailing list

Reply via email to