On Tuesday 27 November 2001 14:50, Seth Burgess wrote: <snip> > Allow me to correct some impressions... > > Very little has happened recently in the way of scripts or filters; saying > that gimp developers concentrate on that is ridiculous. Sorry, my bad. Jargon problem it seems. In Gimp, scripts and filters are Perl and Scheme programs that do things to the image via the Gimp API, which is not really what I meant. I'm no Gimp expert, but what I meant was the whole "drawing engine" part, ie memory management, brush strokes, layers, etc. Attached to it are the scripts and filters, and on top of that is the GUI, right? > I think you seriously overestimate the amount of developers working on it. > The few that do make regular contributions are more than swamped with their > ambitious primary goal of making it cleaner and easier to hack. (Look > through the ChangeLog for the past 12 months - only Mitch and Sven are at > all regular contributors). Okay, so I misjudged the state of development Gimp is in. I remember trying to find out some time ago how hard it would be to contribute things to Gimp, but I gave up pretty soon. In another thread Rebecca Walter suggested creating a TODO for developers that want to help. I'd like to suggest they make a HOWTODO, because even if you want to help, you have this 15MB pile of source in front of you and not much of an idea of where to start. Some time ago I read the documentation that comes with GEGL, which is quite a lot of code too with a weird pseudo-language as an added bonus, but it's much easier to understand the structure of the code if you have a nice doc that explains what's what. > Also, the fact is that the codebase has really outgrown the developer power > to support it; it needs cleaning and restructuring so a developer can go > in, see a sane structure in place, and change what needs to be changed > easily. This is extremely dull work (for me anyway) and we're lucky we > have a couple guys that love the program enough to put the huge amount of > time into fixing it. Amen. This wasn't an attempt to put down Sven, Mitch or any of the other developers. I'm a computer science student and I can certainly appreciate the amount of work that's being put into Gimp. What I didn't realize was that Gimp isn't at all ready for new, user-oriented features at the moment. > When they do get around to making user-centered choices, they tend to do a > good job IMHO. But they are few, and thier task is large - its not all > thats on their plate. > > > And that the maintainers won't accept contributions that don't help > > the users in some way. > > Most of the work being done right now doesn't help the user one little bit, > but should help developers make it easier to help users in the future. > Putting a restriction like this in place would result in complete > stagnation of the tree simply because nobody has the time to learn all the > stuff needed to go in and hack right now. It makes difficult tasks > impossible. You're right, this is nonsense. > Some things won't happen for a while. For example, take CMYK support (or > other colorspace support for that matter). To do this successfully > requires an internal representation thats different throughout. A lot of > work has been done towards this goal (changing spots to use GimpColor, or > separating out colorspace operations from the UI for instance), but a lot > remains as well. The idea is to hopefully get it into 2.0. At our current > release cycle, thats probably 5 years out. Well if you use GEGL for 2.0 it shouldn't be hard as GEGL has been designed from the start with different colourspaces in mind. I like GEGL quite a lot actually, apart from the "we don't need no C++" thing which I understand but disagree with. However, that discussion is closed, and let's keep it that way. <snip - better fonts are coming up> > I think the current regular developers (both of them) as well as the > occasional contributors are all doing great things for the program. They > find time to respond to most feature requests submitted through gnome > bugzilla. If you have specific, well thought out ways of progressing gimp > along without radical change to everything, please do submit your feature > request. Things do get implemented this way, and coders do pay attention. I have a few things in the back of my head (layer trees, a 4x4 matrix for every layer to encode transformations, etc.) but I think those are better suited for GEGL an Gimp 2.0. Lourens
