Sven wrote:
> You obviously didn't understand me. Adding such an API would be a
> major undertaking and we are not going to add such a framework for
> anyone unless that someone has at least built a prototype in the
> core. I do simply not believe that there is serious interest for
> developing other paint tools. People toss these ideas (see above) back
> and forth. If you look at them closely, you notice that they are vague
> and that the changes that are needed to make them possible are huge.
A few months ago I had the idea of trying to develop a paint tool that
would work like the ink tool but would use modules to generate the
paint patterns -- this would be a sort of compromise version of a
pluggable paint tool. As a step toward this goal, I thought I would
try to modify the ink tool so that it would spray paint blobs in a
semi-random pattern. This seems like it ought to be pretty straightforward,
and in principle I believe it probably is, but a few hours of code
study left me completely bewildered. The root problem is that I
don't understand the basic philosophy of code organization in GIMP,
and without such a framework it is very difficult to understand the
function of any given code fragment. And unfortunately these sorts of
high-level abstractions are the most difficult things to figure out
by reading the source code.
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.
And I can tell, just by the feel of the code, that there are
many more such basic facts that I haven't yet been able to figure out.
If you don't understand the basic principles, all of the code just looks
like obfuscated gibberish, no matter how clear and simple the code is
in reality.
I might be interested, once 2.2 is out, in taking another shot at this,
since you are Mitch are showing so much willingness to be helpful. But
it will certainly involve asking a lot of stupid questions.
> If you had serious interest for developing other paint tools, you
> would develop them in the core. There you find a complete and simple
> framework for developing your ideas. The fact that you don't use it or
> not even ask about how it can be done, clearly shows that your
> interest isn't serious. Why should we go through the hassle of adding
> the framework for pluggable tools then?
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. 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.
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.
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.
Best,
-- Bill
______________ ______________ ______________ ______________
Sent via the KillerWebMail system at primate.ucdavis.edu
