Sven Neumann wrote:

Hi,

so far we didn't have a well-defined development roadmap. I would like to propose that this is changed for GIMP 2.6 and beyond. Hopefully this can help to acomplish two goals:

- GIMP 2.6 should not take too long to develop - we will get more developers

Before we start the discussion of the roadmap, perhaps we should talk about how we should go about getting to a roadmap. Should we do it on this list, do we want to use a Wiki, Bugzilla or anything like that?

IMO it would be best if people proposed features here so that they can be discussed on the list. We should then collect these proposals somewhere and try to decide on milestones for them later. It would probably help if we try to be strict bout only proposing a single feature per mail.

What do you think?

Sven

On 10/24/07, Sven Neumann wrote: [...]

IMO it would be best if people proposed features here so that they can be discussed on the list. We should then collect these proposals somewhere and try to decide on milestones for them later. It would probably help if we try to be strict bout only proposing a single feature per mail.

Sound good. Bugzilla seems like overkill until the roadmap is laid out.

I'm not a contributor though - I'm still (slowly) becoming proficient in c/c++. Looking for some low fruit on the GEGL switchover...

Chris

Gimp 2.4 is great!

On roadmaps: could enhancement requests be grouped by category somewhere? Going through the list of enhancement proposals in Bugzilla is rather awkward to say the least.

I do like how some programs have used a wiki, like Firefox 3 and Inkscape. Eventually, for Gimp, each wiki entry could link to a bugzilla entry.

There can be the following categories for example: - Architecture (GEGL, and resulting features such as grouped layers and brushes)
- GUI (with links to that GUI brainstorming blog by the way) - New [insert tool] options (ex: new paint options, I think it could be a good idea to list the tools individually or by category: selection tools, paint tools, etc)
- New tools
- New filters
- New whatever
- Color and format support: CMYK, obscure file formats, etc. - Inter-compatibility: Photoshop gradients, palettes, actions, .psd files, .psp files, enhanced inter-compatibility with other open-source drawing programs such as Inkscape, etc.

After that, a target can be set for individual features ("2.6," "undefined"). Then a separate list can be compiled to show just the features currently being worked on for the next release.

Truth be told, I'd be glad to wait off any visible feature additions if work on GEGL progresses, as to my understanding it is necessary in order to implement some really handy interface enhancements such as grouped layers and grouped brushes.

I'm also pro-shorter development cycles by the way. I really like how Ubuntu handles this for example: the new release doesn't bring a revolution in terms of new features, but it Does bring one or two new features that makes your life much easier, and just for that, people are happier. The single feature I had been waiting for a long time in Gimp 2.4 for example is brush scaling. If Gimp 2.6 were to come out fast with nothing but layer and brush groups as new features, I'm sure people would be very happy rather than complain about a rushed release with not enough new features. I've seen an article put it as "Not biting off more than they can chew."

so far we didn't have a well-defined development roadmap. I would like to propose that this is changed for GIMP 2.6 and beyond. Hopefully this can help to acomplish two goals:

- GIMP 2.6 should not take too long to develop - we will get more developers

Before we start the discussion of the roadmap, perhaps we should talk about how we should go about getting to a roadmap. Should we do it on this list, do we want to use a Wiki, Bugzilla or anything like that?

IMO it would be best if people proposed features here so that they can be discussed on the list. We should then collect these proposals somewhere and try to decide on milestones for them later. It would probably help if we try to be strict bout only proposing a single feature per mail.

What do you think?

Sven

___

What do you think?

I think it's a great idea to have shorter deveopment cycles. It looks like the project is more active and alive. I've heard a lot of people saying that gimp was almost dead, while I was testing 2.3.x series almost monthly. But people tend to think that the activity of a project is measured by the release cycle of stable versions, so this idea will for sure draw more attention to the project (and luckily more developers).

The only problem I see with this idea is the GEGL thing. I'm not a coder, but it looks like a quite radical change in the gimp core, so if that's a goal for 2.6 and the development cycle will be shorter, maybe there is no place for further additions. And if 2.6 has only the migration to GEGL and no extra features, people will say again: gimp is stuck.

Many of the frequently asked features need the GEGL core (or as it has been discussed before, it's pointless to spend much time trying to code them for the current core when the same work using GEGL will be more straightforward). I mean Layer Effects, CMYK color and 16 bpc, improved image scaling etc.
otoh, there are some features that can be implemented without the GEGL migration: Fine tunning of some of the existing tools (angle and axis contrstaints for paths and transform tools, or visibility in the scale and rotate tools, for instance), interface changes, improvements in the text tool, layer grouping, etc.

So, an important decision must be taken, imo. Plan the 2.6 version as a "new core" version (with important improvements in the technical area, but maybe not that visible for the final users), or a "new features" version. If this isn't defined, there is a risk to fall in a long development cycle again.

That's my opinion, of course.

So, an important decision must be taken, imo. Plan the 2.6 version as a "new core" version (with important improvements in the technical area, but maybe not that visible for the final users), or a "new features" version. If this isn't defined, there is a risk to fall in a long development cycle again.

How about a "new core" version, with just a few key features implemented on top of that?

GEGL can?t be delayed forever. Sooner or later the issue has to be tackled. In the meantime, many commonly asked features can?t be implemented without more work on GEGL.

Whenever there?s a new version of Gimp, any given user usually only focuses on 3 or 4 of the new enhancements. The rest may have minimal impact for them.

However, architectural enhancements can usually benefit everybody, so it fills half the new quota they expect from the program already. For example, the ability to configure keyboard shortcuts was for me a bigger improvement than any individual new filter. What stood out for me this version was brush-scaling, though that?s less of an architectural issue. Point is, not all enhancements are of the same level. The basic issues are often the one affecting most people.

A Gimp 2.6 release that says this:

"Gimp has finally implemented layer groups and brush groups. [insert explanation and photos]

This was possible because Gimp has started significant architectural rework by commencing on the long-waited implementation of GEGL.

GEGL is [insert short explanation].

In the near future, GEGL will allow the implementation of other long-awaited features such as native CMYK support, layer effects and other non-destructive editing, much improved image scaling, and more.

Once migration to GEGL is complete, expect faster new features and shorter development cycles. Stay tuned!

In the meantime, if you are a developer and wish to contribute to the development of Gimp, [see here]."

...will not be considered a "poor" release, especially since The developers have bothered to explain just Why GEGL Is being worked on. People will be a bit more patient with "bland" releases if they know that as a result, they Will get the features they had been waiting for soon enough later.

That said, this also depends on the developers. They can't be forced to work on GEGL, either.

___

The things can be visually organized like the Inkscape does: http://wiki.inkscape.org/wiki/index.php/Roadmap . As I think, the roadmap at their site is much late to the current features implemented, but the whole framework represents the picture.

Although there can be something like preliminary voting at the site: what features are the most awaited by the users with the ability to add such a feature if it is absent from the list. This list could help developers a little to know vox populi to make further architectural and schedule decisions. Of course, it wouldn't be a rule, only a reference.

Reading through Russian linux news site, I can express here the most anticipated features GIMP lacks to serve the photographers from the user POV:
1. more than 8 bits per channel.
2. CMYK and Lab
3. layer effects
The significance of the features coincides with their number. So if 2.6 only had more than 8 bits per channel, it would satisfy a great amount of users.

Valerie VK wrote:

So, an important decision must be taken, imo. Plan the 2.6 version as a "new core" version (with important improvements in the technical area, but maybe not that visible for the final users), or a "new features" version. If this isn't defined, there is a risk to fall in a long development cycle again.

How about a "new core" version, with just a few key features implemented on top of that?

GEGL can’t be delayed forever. Sooner or later the issue has to be tackled. In the meantime, many commonly asked features can’t be implemented without more work on GEGL.

Whenever there’s a new version of Gimp, any given user usually only focuses on 3 or 4 of the new enhancements. The rest may have minimal impact for them.

However, architectural enhancements can usually benefit everybody, so it fills half the new quota they expect from the program already. For example, the ability to configure keyboard shortcuts was for me a bigger improvement than any individual new filter. What stood out for me this version was brush-scaling, though that’s less of an architectural issue. Point is, not all enhancements are of the same level. The basic issues are often the one affecting most people.

A Gimp 2.6 release that says this:

"Gimp has finally implemented layer groups and brush groups. [insert explanation and photos]

This was possible because Gimp has started significant architectural rework by commencing on the long-waited implementation of GEGL.

GEGL is [insert short explanation].

In the near future, GEGL will allow the implementation of other long-awaited features such as native CMYK support, layer effects and other non-destructive editing, much improved image scaling, and more.

Once migration to GEGL is complete, expect faster new features and shorter development cycles. Stay tuned!

In the meantime, if you are a developer and wish to contribute to the development of Gimp, [see here]."

...will not be considered a "poor" release, especially since The developers have bothered to explain just Why GEGL Is being worked on. People will be a bit more patient with "bland" releases if they know that as a result, they Will get the features they had been waiting for soon enough later.

That said, this also depends on the developers. They can't be forced to work on GEGL, either.

--
With respect
Alexander Rabtchevich

Regarding the process of developing a roadmap, I think this mailing list should be where proposals are made and commented upon (there has already been some nice commentary in this thread). The "main" GIMP developers should fairly rapidly be able to come to a decision about the roadmap (through discussions on #gimp) and announce the main focal points of the plan. While it is difficult to dictate the direction of volunteers, with a quick release cycle focusing on the development needs of GIMP, programmers might be willing to set aside their own projects temporarily in order to make GIMP more conducive to further developerment.

If I may be so bold, what follows is my own proposal for the 2.6 roadmap:

I think that substituting GEGL into the GIMP core should be the main focus. This should be done in a manner such that the user is not confronted with the directed graph nature of GEGL -- i.e., the user interface limits GEGL nodes to just three drawable inputs: the active layer, the projection of "lower" layers, and the layermask (if present).

The only significant change from a user standpoint should be the addition of "layer groups". From a rendering standpoint, layer groups dictate a certain degree of low-level functionality that would best be addressed during incorporation of GEGL into the core (particularly, "nesting" of composited projections).

From a user interface standpoint, "layer groups" would entail significant changes to the tree view of the layerstack; as well as changes in behavior of certain operations such as raising/lowering, linking/hiding, duplicating/deleting, and drag-n-drop of layers. Implementing this would be a fairly extensive undertaking (probably requiring more developer resources), but would best be handled at the same time as the GEGL incorporation to avoid future conflicts in implementing the appropriate model-view-controller paradigm.

Finally, there should be an effort to maintain integrity of the XCF file format by converting between the core implementation of layer groups and parasites attached to drawables during saves and loads of XCF files (older GIMP versions would read the files but lose the layer grouping information).

Providing "layer groups" would be an evident improvement to GIMP while incorporating GEGL is necessary for furthering development efforts. Issues such as CMYK, layer effects, deeper bit-depth color, and improved text handling would be better addressed once GEGL is embedded into GIMP. Usability enhancements might be pursued, but should not be permitted to prolong the release cycle.

Though I have as yet contributed very little to GIMP development (and nothing towards that of GEGL), I have spent a good deal of time trying to gain an overall understanding and hope to become more helpful in the future.

---------------------------------------------------

Quoting Sven Neumann :

Hi,

so far we didn't have a well-defined development roadmap. I would like to propose that this is changed for GIMP 2.6 and beyond. Hopefully this can help to acomplish two goals:

- GIMP 2.6 should not take too long to develop - we will get more developers

Before we start the discussion of the roadmap, perhaps we should talk about how we should go about getting to a roadmap. Should we do it on this list, do we want to use a Wiki, Bugzilla or anything like that?

IMO it would be best if people proposed features here so that they can be discussed on the list. We should then collect these proposals somewhere and try to decide on milestones for them later. It would probably help if we try to be strict bout only proposing a single feature per mail.

What do you think?

On 10/26/07, saulgoode wrote:

Finally, there should be an effort to maintain integrity of the XCF file format by converting between the core implementation of layer groups and parasites attached to drawables during saves and loads of XCF files (older GIMP versions would read the files but lose the layer grouping information).

IIRC, it was planned to nuke current XCF at some stage of development in favour of an XML based file format (XCF2, OpenRaster, whatever).

Alexandre

A change in file formats should be postponed until a bump in the major version number takes place (per GNU coding standards?). But my proposal of adding parasites containing layer group meta-data to files saved in the current XCF standard is indeed merely an interim solution, permitting time for a new format to be decided upon (not an insignificant task in itself).

Quoting Alexandre Prokoudine :

On 10/26/07, saulgoode wrote:

Finally, there should be an effort to maintain integrity of the XCF file format by converting between the core implementation of layer groups and parasites attached to drawables during saves and loads of XCF files (older GIMP versions would read the files but lose the layer grouping information).

IIRC, it was planned to nuke current XCF at some stage of development in favour of an XML based file format (XCF2, OpenRaster, whatever).

Go for the low-hanging fruit. Do whatever work is easiest that can roll into new releases. If GEGL is toughest, leave that until 2nd, and do the GDK stuff first. Do whatever you have the strongest team for.