Quoting "Joao S. O. Bueno" <gwid...@mpc.com.br>:
> Oliver -
> this rant has no reason to be. Sorry for that.
I disagree. Oliver has politely raised an issue to be discussed and
presents some valid points.
GIMP is nearly a million lines of code -- well over a million if you
take into account GEGL and BABL. If a potential code contributor
examine 1000 lines of code each and every day, it would take nearly
three years before his perusal would be complete.
GIMP employs some rather creative coding approaches which a not
exactly common knowledge to traditionally trained programmers. The
GLIB object system itself is well documented and it is obviously
employed throughout GIMP (and its documentation appropriately linked
to on developer.gimp.org), but how is a potential contributor to learn
the philosophy underlying the various object/method hierarchies? For
example, why is transformation a method of a tool object, and not a
method of the object being transformed? Oftentimes understanding the
reasoning behind programming decisions is useful, if not critical, to
understanding the programming itself.
Libgimp also is not what I would expect an application's library to
be. Instead of being a library of functions which GIMP invokes but are
factored out so other programs can make use them separate from GIMP,
the opposite seems to be the case: libgimp invokes functions internal
to GIMP (other programs can thus use libgimp, but only if GIMP is
In fact, it seems that a libgimp function will typically call a PDB
function, which provides the interface to the internal GIMP function.
Of course the PDB function doesn't exist in the original GIMP source
code but is generated by a Perl script. And the internal GIMP function
isn't called directly but is an invocation of an object's method which
is defined at runtime.
I'm no doubt completely off-base in the above analysis, but then that
is rather the point. How does a potential contributor get from reading
the GTKDOC description of a libgimp function to finding the section of
source code in the GIMP tree that actually implements the function? It
may be just my own incompetence, but I've been unsuccessful more often
than not in doing this.
> Anyway, I've written an article a couplle of months ago that is now
> published here:
> Maybe that fulfills part of what you call "a workshop".
That is precisely the type of documentation of which more is needed to
encourage participation in the GIMP project -- both the GIT tutorial
and the "how to write a tool". I applaud your effort and hope you
would consider additional installments (if you are considering further
installments, might I propose "how to expose an internal GIMP function
to the PDB").
> Now, please - these kindof rants won't change anyones atitude in here
> - the developers willjust feel ill towards you. Keep experimenting,
> trying, learning, and asking about code - refrain from rants: they
> just take us nowhere.
I can certainly understand the GIMP developers not being enthusiastic
about writing development documentation, but that does not mean that
the existing gaps aren't problematic for potential contributors.
Perhaps a solution can be found that doesn't require an "attitude
change", but still seeks to address the issue. Maybe a "contributors
wiki" could be created, where those of us who are trying to learn
GIMP's codebase can create documentation from our experiences, and the
more knowledgeable developers could visit periodically and fix things
that are inaccurate (if such a wiki were created, I'd volunteer to
Gimp-developer mailing list