Re: [Gimp-developer] shorthanded and outnumbered (Re: Native RAW support)
On Mon, 2010-09-20 at 20:13 -0400, saulgo...@flashingtwelve.brickfilms.com wrote: 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. That's why we have the devel-docs folder in the GIMP source tree where we try to explain the structure of the source code and document the internal and external APIs as well as file formats. Sure, there should be more documentation like this. Everyone is invited to contribute. 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). Taking your example, the role of libgimp is explained in devel-docs/structure.xml. Sure, this documentation could be extended to make things even more clear. Everyone is invited to contribute. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] shorthanded and outnumbered (Re: Native RAW support)
On Mon, Sep 20, 2010 at 01:39:42PM +0400, Alexandre Prokoudine wrote: [...] The way things are going native RAW support in GIMP using GEGL + some can-opener library will likely require a dedicated developer in the team. Which the team doesn't seem to have right now, being heavily shorthanded and outnumbered. [...] A problem I talked about with people more than once. I for myself like writing code from scratch and find it very annoying and exerting to work with code I don't know. So what I often asked for is something like an overview on the Gimp-code. A documentation could help, but I personally would prefer workshops, where I can ask the more expereienced developers on who things are done. This saves a lot of time and can motivate people. Otherwise some developers that could help a lot would just do different things. I looked at Gimp's code, and it's much code. I don't know how other people see it, but such an intro-workshop would make sense to me. It's just a matter of effective work. Some things can be said in one or two sentences as answer for a question, or otherwise would take people weeks to get it from documentation (or even longer, if the docukmentation is spare or outdated). Different people, different working and learning styles. If thge core developers insiste that poeple who want to help has to have frustrating time consuming experiences with other people's code first, than no wonder development has slow progress. Some weeks ago I asked on irc for some help in gimp script programming. The answers I got were rather uninformed - from people who seem to be developers in Gimp. No useful answer, rather rhetoric questions instead of answers. I then got the answer from someone else, who has nothing to do with Gimp coe development, but did a lot Gimp scripting. For me this was again something like: even the core developers don't know Gimp, but someone else, who rather is artist and does some scripting for himself, knows the details. IMHO this comes from the behaviour that people just look at some code, start to hack and don't know the rest of the program. And I would guess, that's, because there is nobody who has an overview, or at least nobody who want's to provide that knowledge in a way that other people can jump in more easily - withgout just looking at some small portions of the code. The time that is needed to look into a big bunch of code could also, maybe more effectively be used to write something different from scratch. And that's maybe the reason, or at least one of the reasons, why there are not enough people that work in the Gimp core (shorthanded and outnumbered). Ciao, Oliver ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] shorthanded and outnumbered (Re: Native RAW support)
On Mon, Sep 20, 2010 at 7:38 AM, oli...@first.in-berlin.de wrote: On Mon, Sep 20, 2010 at 01:39:42PM +0400, Alexandre Prokoudine wrote: [...] The way things are going native RAW support in GIMP using GEGL + some can-opener library will likely require a dedicated developer in the team. Which the team doesn't seem to have right now, being heavily shorthanded and outnumbered. [...] Oliver - this rant has no reason to be. Sorry for that. It makes no sense to start working in a project the size of GIMP without having to learn the code already in there first. What do you mean by a workshop? Like a physical face to face class, where one would be pointing this is the tools directory, inside it there are the files that ,make for the tool classes...? Not shure if that could help. 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. 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. regards, js -- (...) Ciao, Oliver ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] shorthanded and outnumbered (Re: Native RAW support)
On Mon, Sep 20, 2010 at 09:25:12AM -0300, Joao S. O. Bueno wrote: On Mon, Sep 20, 2010 at 7:38 AM, oli...@first.in-berlin.de wrote: On Mon, Sep 20, 2010 at 01:39:42PM +0400, Alexandre Prokoudine wrote: [...] The way things are going native RAW support in GIMP using GEGL + some can-opener library will likely require a dedicated developer in the team. Which the team doesn't seem to have right now, being heavily shorthanded and outnumbered. [...] Oliver - this rant has no reason to be. Sorry for that. It makes no sense to start working in a project the size of GIMP without having to learn the code already in there first. [...] I didn't say people should not look into the code. I meant: before looking into the code, an OVERVIEW on the code base would be helpful. Looking into the code without an overview yields to people with too narrow view on the code. Maybe that is good for other people, but not for me. I say it again: there are different styles of work. Is this is not addressed, then it makes no sense to mourn about shorthanded and outnumbered developers. If that situation should be changed, new developeers should be invited. And not everybody who could contribute will have enough time to read Megabytes of Code, just for fun. Ciao, Oliver ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] shorthanded and outnumbered (Re: Native RAW support)
On 20 September 2010 15:10, oli...@first.in-berlin.de wrote: Is this is not addressed, then it makes no sense to mourn about shorthanded and outnumbered developers. You're more than welcome to address the issue. -- Regards Jon Nordby - www.jonnor.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] shorthanded and outnumbered (Re: Native RAW support)
On 9/20/10, oliver wrote: On Mon, Sep 20, 2010 at 01:39:42PM +0400, Alexandre Prokoudine wrote: [...] The way things are going native RAW support in GIMP using GEGL + some can-opener library will likely require a dedicated developer in the team. Which the team doesn't seem to have right now, being heavily shorthanded and outnumbered. [...] A problem I talked about with people more than once. Not here, perhaps? :) So what I often asked for is something like an overview on the Gimp-code. A documentation could help, It is true that dev documentation is lacking essential bits for new developers. Barak Itkin used to have beginnings of GIMP's architecture overview. I wonder what stage the document is in :) but I personally would prefer workshops, where I can ask the more expereienced developers on who things are done. Workshops organized by...? Where? On whose money? This saves a lot of time and can motivate people. You live in Germany, as several GIMP developers do. Last thing I heard is that developers want to have a face-to-face meeting some time around release of 2.8 or maybe before (if I got that right). Thy will be occupied with things, but maybe they can find time to talk to you as well? Otherwise some developers that could help a lot would just do different things. In my experience people who really want to contribute find IRC good enough for discussing things. This is how the project acquired some of our most valuable contributors despite of lacking documentation and no workshops. Some weeks ago I asked on irc for some help in gimp script programming. The answers I got were rather uninformed - from people who seem to be developers in Gimp. Seem to be or are developers? Do you understand that you base your judgments on an assumption and proceed with them as if the assumption was correct? This is not nice really. No useful answer, rather rhetoric questions instead of answers. That still keeps a possibility of a question asked in a particular style :) I then got the answer from someone else, who has nothing to do with Gimp coe development, but did a lot Gimp scripting. So the problem was solved then? Alexandre Prokoudine http://libregraphicsworld.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] shorthanded and outnumbered (Re: Native RAW support)
On Mon, Sep 20, 2010 at 2:10 PM, oli...@first.in-berlin.de wrote: Oliver - this rant has no reason to be. Sorry for that. It makes no sense to start working in a project the size of GIMP without having to learn the code already in there first. [...] I didn't say people should not look into the code. I meant: before looking into the code, an OVERVIEW on the code base would be helpful. Looking into the code without an overview yields to people with too narrow view on the code. Maybe that is good for other people, but not for me. I'll bite ツ There is various libraries that GIMP depends on: glib - does portable reusable low level data structures, and includes GObject which provides the basis for OOP in GIMP gtk+ - is a UI toolkit that was created for use with GIMP that is now widely used also elsewhere babl - is a pixelformat conversion library that provides dynamic and efficient conversion of pixel formats. GEGL - is a graph based image processing framework that together with its plug-ins is destined to replace almost all code in GIMP and its plug-ins, doing work on the legacy 8bit code in GIMP will most often result in the brave new world promised by GEGL to be further postponed. I maintain two of these projects, babl and GEGL, the following links point to overviews of the directory structures used for their source codes: http://gegl.org/#_directory_overview , http://gegl.org/babl/#DirectoryOverview /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] shorthanded and outnumbered (Re: Native RAW support)
On Mon, Sep 20, 2010 at 05:31:07PM +0100, Øyvind Kolås wrote: On Mon, Sep 20, 2010 at 2:10 PM, oli...@first.in-berlin.de wrote: Oliver - this rant has no reason to be. Sorry for that. It makes no sense to start working in a project the size of GIMP without having to learn the code already in there first. [...] I didn't say people should not look into the code. I meant: before looking into the code, an OVERVIEW on the code base would be helpful. Looking into the code without an overview yields to people with too narrow view on the code. Maybe that is good for other people, but not for me. I'll bite ツ There is various libraries that GIMP depends on: [...] I maintain two of these projects, babl and GEGL, the following links point to overviews of the directory structures used for their source codes: [...] Thanks. I already have decided to write some code on top of GEGL. If it progresses as I hope, this will be something that I will use instead of Gimp-scripting. Nevertheless a program wiuth GUI would be fine, so I hope Gimp will progress fast, if not with my help, then maybe without it. Ciao, Oliver ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] shorthanded and outnumbered (Re: Native RAW support)
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 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@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
