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:
> http://www.ibm.com/developerworks/linux/library/os-gimp/index.html?ca=drs-
> 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  
administrate it).

Gimp-developer mailing list

Reply via email to