Hi, I'ts been a while since I've last written here. First of all congrats for getting 2.4 out the door. I'm not a developer, just a humble graphic artist & semi-professional UI designer.

I think making a roadmap is a very important step in the development of Gimp. But I suggest before that, Gimp needs a mission statement. If you've happened to read the talkback on /. to the release announcement, you may have noticed most people compared Gimp to Photoshop and complaining on its shortcomings. I think a clear message as to the direction Gimp development will take in the future is important. The choice is simple: Professional tool for the Graphic artist, or image editor for the home user and amateur photographer. Mozilla suite - or Firefox.

I believe Gimp's target audience should be the home user and amateur photographer, and future development in this direction should take precedence over features for the professional artist. Gimp is already a default install in many distros. Many more people will benefit from a simple, easy to use tool that will enable them to create web art and modify pictures than they will from a complex app crammed full of incomprehensible functions. But this must be written down and displayed on the website so everyone can see and understand just what is Gimp and where it is going.

Back to the subject of the roadmap. As well as a guide for future development, a roadmap can be used to recruit potential developers by creating a vision for the future of Gimp which will inspire them to join the effort. I believe the internals work is important and necessary, but it does not inspire. Perhaps a roadmap should be drawn for the next two or three releases, leading up to Gimp 3. If the vision is attractive enough (and accompanied by detailed mockups and design documents), more people will want to join in and will agree to do some grunt work, knowing what all the hard work will eventually lead to.

As for user-visible changes in version 2.6, I think an important goal should be to get Gimp to work well with the desktop environment. I'm talking about the multiple taskbar buttons and related subjects. I'm writing this on Ubuntu 7.10 and Gimp is showing some strange window behaviours here. I know similar thigs are happening in the Windows port. If there's anything most users will appreciate it's this.

Michael

----- Original Message ---- From: Sven Neumann
To: gimp-developer@lists.XCF.Berkeley.EDU Sent: Friday, October 26, 2007 9:25:46 AM Subject: [Gimp-developer] 2.6 roadmap

Hi,

so it looks like we should toss some ideas around here on the mailing-list to get an idea what could be our goals for 2.6. Let me just
propose a few things for discussion:

On 10/26/07, Micahel Grosberg wrote:

I think making a roadmap is a very important step in the development of Gimp. But I suggest before that, Gimp needs a mission statement.

It already has one

http://gui.gimp.org/index.php/GIMP_UI_Redesign#product_vision

Alexandre

Micahel Grosberg wrote:

I believe Gimp's target audience should be the home user and amateur photographer, and future development in this direction should take precedence over features for the professional artist.

Could I object? Currently GIMP is one and the only potential free OS tool for real graphic amateurs and professionals. As more and more people buys DSLRs the amount of users who need high quality tool for photo retouching increases. That can be added by the people who leaves Windows for Linux.
And the others who can, but do not want to use this particular tool can use _many_ other simplier solutions. Dis I say Krita or F-Spot or..?

-- With respect
Alexander Rabtchevich

Micahel Grosberg wrote:

I believe Gimp's target audience should be the home user and amateur

photographer, and future development in this direction should take precedence over features for the professional artist.

First of all, sorry by the "caveman's english".

I'm a professional artist and I change from Photoshop to Gimp just because it contains the best tool kit to make my work each time better and efficient, so in the "mission statement", i think it must include guys like me.

About the road map:

I've entered in the developers mailing list just about now and my intent is help like a "Beta tester" and help with videos and tutorials. I'm very interested in the Gimp Gap tools. Improve the Onionskin and the main interface of Gap (wich are the most important things to the traditional animator and they doesn't actually works). Other thing, the "pop ups" in the transform tools some times are very annoying, i think must be another solution for them.

congratulations for this great software! Daniel

2007/10/26, Alexander Rabtchevich :

Micahel Grosberg wrote:

I believe Gimp's target audience should be the home user and amateur

photographer, and future development in this direction should take precedence over features for the professional artist. Could I object? Currently GIMP is one and the only potential free OS tool for real graphic amateurs and professionals. As more and more people buys DSLRs the amount of users who need high quality tool for photo retouching increases. That can be added by the people who leaves Windows for Linux.
And the others who can, but do not want to use this particular tool can use _many_ other simplier solutions. Dis I say Krita or F-Spot or..?

-- With respect
Alexander Rabtchevich

So... Gimp currently has 4 major goals? - Cairo
- GEGL
- Add named parameters and default values to the PDB - 6 months development cycle.

Wouldn't it be easier to treat them as Separate goals for separate releases? Once Cairo and GEGL (I have no idea for the Parameters feature, so apologies for not being able to say more about it) have been properly implemented, Gimp should have the foundations for rolling out features more quickly. Wanting two at the same time though seems to be asking too much, and proper implementation of GEGL in my opinion justifies one final long development cycle.

Maybe something like this can be considered:

Gimp 2.6: - implementation of Cairo (get this out of the way) - start background work on GEGL, by dedicating more developer resources (if possible) to actually coding GEGL without necessarily implementing it yet
- bunch of other easier features to keep people happy - development cycle: 6 months to a year.

Gimp 2.8: - GEGL integration
- the background GEGL work that started with Gimp 2.6 should have paved the foundations for slightly faster integration - the development cycle will probably still be long, but this will be the last "long" release cycle.

Gimp 3.0+: - with GEGL properly implemented, from now on, development cycles will be 6 months.

Once GEGL has been implemented, the following features seem to be the most demanded ones:
- CMYK
- 16 bit
- layer effects
- layer groups

Any one of the above could justify a minor release. Having the first GEGL-version of Gimp ship with one of the above features would justify the time spent on it, especially if the developers explain that the other features will follow fast. Having said first GEGL-version of Gimp ship with Two of the above would be fantastic.

___

On 10/27/07, Valerie VK wrote:

So... Gimp currently has 4 major goals? - Cairo
- GEGL
- Add named parameters and default values to the PDB - 6 months development cycle.

Wouldn't it be easier to treat them as Separate goals for separate releases? Once Cairo and GEGL (I have no idea for the Parameters feature, so apologies for not being able to say more about it) have been properly implemented, Gimp should have the foundations for rolling out features more quickly. Wanting two at the same time though seems to be asking too much, and proper implementation of GEGL in my opinion justifies one final long development cycle.

Maybe something like this can be considered:

Gimp 2.6: - implementation of Cairo (get this out of the way) - start background work on GEGL, by dedicating more developer resources (if possible) to actually coding GEGL without necessarily implementing it yet

Okay I want to clear this up:
GEGL *is* coded (see www.gegl.org), and already in use by a few different applications.
It works. Getting it working fast and bugfree, though (for instance, good caching behaviour), will be driven by use in GIMP, which will help to locate slow and buggy areas of GEGL. Initial integration will probably be a fussy business, rather than a particularly large one -- making sure that a) it's used right and b) the parts that should use it, do use it.

The only major point for GEGL that is currently known that would make integration with GIMP difficult, is 8bit-specific code; GEGL Ops that accept and output 8bit integral RGBA instead of 32bit float RGBA. I believe many of these can be created automatically by modifying the current code, which already handles generating float versions of porter-duff ops and blending ops. In the mean time, a single conversion op (float -> 8bit int) could be made.

- bunch of other easier features to keep people happy - development cycle: 6 months to a year.

Gimp 2.8: - GEGL integration
- the background GEGL work that started with Gimp 2.6 should have paved the foundations for slightly faster integration - the development cycle will probably still be long, but this will be the last "long" release cycle.

Gimp 3.0+: - with GEGL properly implemented, from now on, development cycles will be 6 months.

Once GEGL has been implemented, the following features seem to be the most demanded ones:
- CMYK
- 16 bit
- layer effects
- layer groups

It's worth a minute to point out the notable, and deserved, absence of adjustment layers from this list. People have had a few discussions (here? certainly on bugzilla.) about this topic, and it arose that: a) Adjustment layers are generally an ugly, complicated idea b) They are also an unnecessary idea -- the combination of layer effects and layer grouping can produce the same effects in a much more sensible way.

(for the reference of anyone who was considering bringing this topic up ;)

Any one of the above could justify a minor release. Having the first GEGL-version of Gimp ship with one of the above features would justify the time spent on it, especially if the developers explain that the other features will follow fast. Having said first GEGL-version of Gimp ship with Two of the above would be fantastic.

___

Okay I want to clear this up:
GEGL *is* coded (see www.gegl.org), and already in use by a few different applications.

Much apologies. I was always under the impression that while there is a working version, more work could have been used for adding features and such. I blame my lack of understanding of what GEGL is supposed to Do, as opposed to what it will Allow Gimp to do.

It works. Getting it working fast and bugfree, though (for instance, good caching behaviour), will be driven by use in GIMP, which will help to locate slow and buggy areas of GEGL.

This makes sense.

Initial integration will probably be a fussy business, rather than a particularly large one -- making sure that a) it's used right and b) the parts that should use it, do use it.

Basically, what's needed is a roadmap of how GEGL will be integrated? Complete with a definition of all the parts that need to use it, and how?

Maybe this should be developed before a Gimp roadmap is defined? This way developers would have a better idea of how much work will need to be done to integrate GEGL, and how it can be distributed into different releases.

It's worth a minute to point out the notable, and deserved, absence of adjustment layers from this list. People have had a few discussions (here? certainly on bugzilla.) about this topic, and it arose that: a) Adjustment layers are generally an ugly, complicated idea b) They are also an unnecessary idea -- the combination of layer effects and layer grouping can produce the same effects in a much more sensible way.

Thanks for the explanation! I actually had no idea what the difference between adjustment layers and layer effects is supposed to be, so didn't dare to add it twice. ;)

___

On 10/27/07, Valerie VK wrote:

Okay I want to clear this up:
GEGL *is* coded (see www.gegl.org), and already in use by a few different applications.

Much apologies. I was always under the impression that while there is a working version, more work could have been used for adding features and such. I blame my lack of understanding of what GEGL is supposed to Do, as opposed to what it will Allow Gimp to do.

It works. Getting it working fast and bugfree, though (for instance, good caching behaviour), will be driven by use in GIMP, which will help to locate slow and buggy areas of GEGL.

This makes sense.

Initial integration will probably be a fussy business, rather than a particularly large one -- making sure that a) it's used right and b) the parts that should use it, do use it.

Basically, what's needed is a roadmap of how GEGL will be integrated? Complete with a definition of all the parts that need to use it, and how?

Maybe this should be developed before a Gimp roadmap is defined? This way developers would have a better idea of how much work will need to be done to integrate GEGL, and how it can be distributed into different releases.

Yes, that would be a good idea. It's easy to get lost in the GIMP code, so a way to limit what developers need to look at would probably attract more developers.

It's worth a minute to point out the notable, and deserved, absence of adjustment layers from this list. People have had a few discussions (here? certainly on bugzilla.) about this topic, and it arose that: a) Adjustment layers are generally an ugly, complicated idea b) They are also an unnecessary idea -- the combination of layer effects and layer grouping can produce the same effects in a much more sensible way.

Thanks for the explanation! I actually had no idea what the difference between adjustment layers and layer effects is supposed to be, so didn't dare to add it twice. ;)

Actually I think I didn't explain the difference between adjustment layers and layer effects.

Adjustment layer: a layer that modifies the layers below it, without actually contributing pixel data. An adjustment layer as used in Photoshop, has a mask, but no pixel data. http://www.phong.com/tutorials/adjust/ provides some examples, including eg. Curves adjustment.

Layer effect: an effect attached to a layer -- for example, "Drop shadow" is a layer effect provided by Photoshop. Takes the layer pixel data and applies some effect to it. May have a mask, and does not have its own pixel data, so the only difference is the way it's attached to a specific layer.
Peter suggested here:
http://www.mmiworks.net/eng/publications/2007/05/lgm-top-gimp-user-requests_25.html that layer effects could be thought of (and displayed as) a stack per-layer, sitting underneath the layer.