Sven wrote:
> 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.
That isn't quite what I have been saying. Some types of hacking on
the core are relatively easy, others are very difficult. Rearranging
tool options, for example, or changing the anti-aliasing of the
ellipse-select tool, are quite straightforward. And some of the
difficult things are difficult because they involve fancy mathematics
or need to be extremely efficient; there is nothing to complain about
in that. The problem is that, in my experience, nearly anything
involving the object hierarchy is very difficult because the object
interfaces have never been explicitly defined: there is no way to
tell what each object class is supposed to be doing except by reading
its code and the code of the things that use it -- or by constantly
badgering people with questions.
I'm not just making this up, I'm reporting my own repeated
experiences. I feel ten times as productive working on plug-ins as
working on the core. This isn't because plug-ins are intrinsically
easier, it's because the api docs are so wonderful. When I'm doing
plug-in hacking, I constantly have the api docs open (for GIMP and
Gtk), and spend probably half of my time navigating around in them.
When I run into libgimp features that are not documented, I'm nearly
as helpless as when working with the core. (For example, the Pixel
Fetcher. If I ever needed to use one, I would be screwed.)
Let me again be concrete. Consider the problem of making item
displays (brushes, patterns, etc) hierarchical instead of flat --
something that is extremely desirable. In principle it shouldn't be
so hard if you understand how to use tree view widgets (which I do,
although I don't like them particularly). And in principle the GIMP
hierarchical organization should be very helpful, because it means
that most of the work can be done in a few places. But in reality it
means that only Mitch has any hope of doing it, because it involves
making changes in (if I remember correctly) GimpDataFactory,
GimpContainerTreeView, and/or GimpContainerEditor, all of whose
roles and interactions are undefined, and all of which are inherited
by many different things, with no explicit rules for the ways they are
used. The result is that any change is a shot in the dark, which will
probably break things all over the place.
Now I completely understand how huge a task it is to produce such
documentation, and I am not at all trying to cast blame. It's
especially burdensome because the most important parts can't be done
entirely by volunteers -- an explanation of the purpose of an object
class has to come at some point from the person who created it.
Instead a more proper attitude is that the excellent documentation for
the GIMP libraries is amazingly great -- there is no other open source
application with anything comparable. (Libraries and toolkits, yes,
but not applications.) But I am annoyed to be told that I am
spreading FUD when I am simply saying things that in my experience are
true.
Karine Proot wrote:
> I have to back up Sven here.
>
> I am currently trying to get my nose in the code by submitting patches
> to easy-fix bugs. I asked him and other developers very stupid questions
> and they always have answered nicely and helpfully. It is quite obvious
> that they will help people trying to hack the core, as these very people
> can become Gimp developers later, and giving them some answers when they
> are stuck is far more productive than doing it for them. It took them
> between 15 seconds and 3 minutes to answer each of my stupid questions,
> which is far less than the time required to build a tutorial. And above
> all, trying to make my way into the code before giving up and shamefully
> asking those questions, made me understand the Gimp code a bit more each
> time, which you cannot achieve if you only follow a tutorial written for
> you.
>
> The Gimp developers took the time to add 'easy-fix' keyword to some
> bugs. This can be seen as a waste of time as they could fix these
> themselves in short time, but it would be harder for beginners to help
> them and they may lose some help offers. What I am trying to tell is :
> if Sven says it's easy, then it is. Maybe you'll struggle with some
> parts of the code, but if you try it and ask precise questions when
> you're lost I am positive you'll get an answer to help you go on.
>
> Granted, this takes some time, but it is no duty and you can do it at
> your pace (mine is very slow!)
>
> I hope you will give it another try.
I understand why you wrote this, because if you haven't followed GIMP
development for very long, my email could easily be read as coming
from a newbie who took one look at the core and fled in horror, but
the fact is that I have written half a dozen plugins, worked on quite
a number more, and made a substantial number of contributions to the
GIMP core and libraries (mostly pretty minor). Around July I switched
from code writing to writing help docs because I thought that was the
place of greatest need, and currently I'm too bogged down in other
things to do much GIMP-related (other than write way-too-long emails,
damn it!), but I'm not going away. Anyway, thanks for your kind
response.
Best,
-- Bill
______________ ______________ ______________ ______________
Sent via the KillerWebMail system at primate.ucdavis.edu
_______________________________________________
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
