Quoting "Joao S. O. Bueno" <gwidion@xxxxxxxxxx>: > 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 running). 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 Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
