On 10/8/07, Andrew Young wrote:

Greetings!

I have been an avid Gimp user for a number of years. I have always wished Gimp supported non-destructive image adjustments such those available with Photoshop "adjustment layers." From searching around the internet, it seems I am not alone in this wish. However, I haven't been able to find solid information on whether they are planned, under development, or sitting in a pile of nice-to-have enhancements waiting for attention. Rather than continue to wish for them, I am considering joining the development team and implementing them myself. Are there others currently working on this feature? If so, how can I help? If not, has anyone put some serious thought into how this could be implemented?

Hi, non-destructive adjustments are going to be implemented via GEGL (www.gegl.org) - after the final 2.4 is released will be the time to work on this in GIMP (indeed, GEGL integration is the entire purpose of the 2.4...2.6 development cycle.); other than that, there is http://gimp-brainstorm.blogspot.com/ for working out the UI (and http://www.mmiworks.net/eng/publications/labels/GIMP.html , the precursor).
Feel free to contribute to the brainstorming process or to GEGL, and eventually to GIMP as it enters the 2.6 dev cycle.

Is anyone looking for a new feature to work on and would be interested in helping me?

Andy

On 10/7/07, Andrew Young wrote:

I have been an avid Gimp user for a number of years. I have always wished Gimp supported non-destructive image adjustments such those available with Photoshop "adjustment layers." ... Is anyone looking for a new feature to work on and would be interested in helping me?

http://www.gegl.org/#Features
Bullet item number 2.

Features

- 8bit, 16bit integer and 32bit floating point, RGB, CIE Lab, and Y'CbCr output.
- Non destructive editing
- C, C# ,
Pythonand
Ruby interfaces.
- Extendable through plug-ins.
- XML serialization format (not-finalized) - Iterative processing.

....

David Gowers wrote:

there is http://gimp-brainstorm.blogspot.com/ for working out the UI (and http://www.mmiworks.net/eng/publications/labels/GIMP.html , the precursor).

let me clarify a bit:

http://gui.gimp.org is the place where the interaction team works.

http://www.mmiworks.net/eng/publications/labels/GIMP.html is where I write about working on GIMP. I plan to write more there about the direction the GIMP UI will take.

http://gimp-brainstorm.blogspot.com/ is the place where everybody can contribute with their ideas for the UI.

--ps

founder + principal interaction architect man + machine interface works

http://mmiworks.net/blog : on interaction architecture

On 10/8/07, Andrew Young wrote:

David,

Interesting. GEGL sounds very much in line with a lot of the ideas I have about how to approach the problem. Is this seen as the future of GIMP's core?

Image representation, certainly. Gimp's core -- maybe. That would depend on how it interacts with the procedural database.

How big an effort is the port to GEGL expected to be? It sounds like an exciting time to join the development team.

We'll know once it's started :)

You mentioned that GEGL integration is slated for 2.4...2.6 development. Where can I find more information on plans for GIMP's development cycles? Are these documented somewhere on developer.gimp.org?

AFAIK no, it was decided fairly informally, like in many OSS things -- people talked, it became the accepted idea over time, and nobody much mentioned it outside of the GEGL-developer and GIMP-developer mailing lists where it was discussed. Officially I believe Sven has said something to the effect of 'there is no roadmap; people implement things because it's fun or they need it, not because there is a deadline.'

David Gowers wrote:

You mentioned that GEGL integration is slated for 2.4...2.6 development. Where can I find more information on plans for GIMP's development cycles? Are these documented somewhere on developer.gimp.org?

AFAIK no, it was decided fairly informally, like in many OSS things -- people talked, it became the accepted idea over time, and nobody much mentioned it outside of the GEGL-developer and GIMP-developer mailing lists where it was discussed. Officially I believe Sven has said something to the effect of 'there is no roadmap; people implement things because it's fun or they need it, not because there is a deadline.'

I just have to flank in with a little comment here.

In the open source world work can also be made when companies hire people to implement a certain feature. Unfortunately there haven't been so much interest yet from companies to hire people to work on GIMP. Personally I hope that will change, and I have some plans on how to do that, but that's a post-2.4 subject.

Regarding when 2.4 is released, it should be out pretty soon, I'd guess some time this week, the next week, or the week after that.

Martin Nordholts

Hi,

On Mon, 2007-10-08 at 21:29 +0930, David Gowers wrote:

AFAIK no, it was decided fairly informally, like in many OSS things -- people talked, it became the accepted idea over time, and nobody much mentioned it outside of the GEGL-developer and GIMP-developer mailing lists where it was discussed.

We keep announcing this for quite a while. As soon as 2.4 is done, we will start to port some internals to GEGL. Since we don't want the next development cycle to last forever (again), it remains to be seen how much effect this will have feature-wise. It might turn out that GIMP 2.6 becomes a GEGL driven version of GIMP that provides pretty much the same feature set as GIMP 2.4 and only uses GEGL internally.

Officially I believe Sven has said something to the effect of 'there is no roadmap; people implement things because it's fun or they need it, not because there is a deadline.'

Well, for GIMP 2.6 and beyond we will need a roadmap. But everyone should be busy hacking on 2.4 or preparing the release, so let's wait until that is done.

Sven

On Wednesday 10 October 2007 13:30:16 Andrew Young wrote:

Please excuse the noob question. Why are there no odd numbered releases? e.g. 2.5? Do they have a special, internal role?

According to old tradition, odd version numbers like 2.5 are for development versions. There was Gimp 2.3 but it was never marked stable instead the stable release is now named 2.4. The same versioning system is used in the Linux kernel. Gimp 2.5 will be the development tree for version 2.6.

Christoph

On Wednesday 10 October 2007 13:30:16 Andrew Young wrote:

Please excuse the noob question. Why are there no odd numbered releases? e.g. 2.5? Do they have a special, internal role?

It has been a long standing tradition amongst many (open source) programs that odd numbered minor numbers indicate a development version and an even numbered minor number is a "stable" release version.

This practice goes back to the earliest days of the 1.0/1.1 Linux kernels (and possibly earlier). Recent changes in the Linux kernel development process mean that it no longer strictly adheres to this rule but GIMP does.

Development releases aren't guaranteed to be stable or even run at all (in some cases). This is where new features can be added, old features may be changed or enhanced, or the code may be restructured. All of these things can make the code unstable, especially during the early stages of a development version.

Hi,
mathwizard@gmx.de (2007-10-10 at 1344.25 +0200):

On Wednesday 10 October 2007 13:30:16 Andrew Young wrote:

Please excuse the noob question. Why are there no odd numbered releases? e.g. 2.5? Do they have a special, internal role?

According to old tradition, odd version numbers like 2.5 are for development versions. There was Gimp 2.3 but it was never marked stable instead the stable release is now named 2.4. The same versioning system is used in the

^ was

Linux kernel. Gimp 2.5 will be the development tree for version 2.6.

GIMP keeps on with the odd for devel (new features) and even for stable (bug fixes only, polish features at best). Linux kernel is currently at 2.6 and there is no parallel 2.7, any changes go to 2.6 directly (last cycle that did was the 2.4 - 2.5 pair).

GSR