Hi,

On Tue, 2007-11-06 at 12:42 -0300, Guillermo Espertino wrote:

Roadmap will be closed by the end of this week, so I'd like to make a summary of the main issues I'd like to see fixed for 2.6

Nice to remind us of some issues but we are not going to put user wishes on our roadmap. It is rather distracting to post user wishes to the developer list. People here should be aware of the shortcomings and without being a developer, your opinion is just one of many users.

But let's look at some of your suggestions nevertheless...

1) Semi transparent overlay of the original layer when transforming (scale or rotate).
(It seems pretty obvious with the planned Cairo support)

This is not obvious, nor trivial, to solve with Cairo. Perhaps we can solve it for 2.6, perhaps not. I expect that this will be an issue until we have fully switched to GEGL. That means for a few more years.

2) Redrawing speed at
Redrawing when a large image is zoomed out is still slow. the quality of the display is excelent, but just turning on or off a layer (for instance) is slow.

I wouldn't say it's slow and I am surprised that you are saying that it is. There are however some optimizations to the display and preview code that I am planning to do for 2.6.

3) Axis Constrain for move tool.
This is very, very useful.

Sure. But it has been on our roadmap for years and no one seems interesting in fixing it. So unless a developers feels like working on this one, it will stay unimplemented.

4) Angle constrain for path tool. Afaics in the documentation, this feature existed in previous versions. Was it removed?

As far as I know this never existed.

7) I left this for the end because I don't know if it will be possible at this stage:
The text tool needs improvements. I don't know if they can be made before GEGL or it should be bumped to a future version. - Text edition on canvas.
- modify text properties "inline" (selecting a part of the text and changing the options doesn't change the whole paragraph). - Don't destroy transformations when editing text properties.

Same answer here. This is on our roadmap for years already and it is very well possible. There is even code for some of this that just needs to be finished. But without someone working on it, this is not going to happen ever.

Sven

Hi,

On Wed, 2007-11-07 at 11:37 -0300, Guillermo Espertino wrote:

What I suggested are not "my wishes". I'm a professional designer and GIMP is a tool for my work. The things that I wrote are issues that make my work more difficult, while they shouldn't.

We are way past this point. The problem and shortcomings of GIMP are clear. What we need now is a roadmap for fixing them and we need developers who are willing and capable to work on this. Going back to step one is not helpful.

Sven

On Wed, 07 Nov 2007 15:37:05 +0100, Guillermo Espertino wrote:

Sven Nwumann wrote:

Nice to remind us of some issues but we are not going to put user wishes on our roadmap. It is rather distracting to post user wishes to the developer list. People here should be aware of the shortcomings and

Should be maybe but apparently aren't otherwise they would never have been designed in in the first place. This is the problem with a code centred definition of development.

without being a developer, your opinion is just one of many users.

But let's look at some of your suggestions nevertheless...

Dear Sven:
What I suggested are not "my wishes". I'm a professional designer and GIMP is a tool for my work. The things that I wrote are issues that make my work more difficult, while they shouldn't. I tried to describe problems in a common workflow that need to be solved, not specific requests of my preference. I'm not asking for a save for web plugin, a "slicer" tool, or a plugin for a specific application. They're simple annoyances that make using gimp less effective for common tasks of image manipulation

I find it rather arrogant to presume that those who can code are the only ones who can contribute to development and as a consequence anyone who can code is also an authority on graphic design and UI implementation.

One of the main reasons for the poor state of gimp UI and many of it's other short-comings is this blinkered idea that unless you can code and are familiar with GTK+ Glib et al you cannot contribute.

Codeing is clearly the core activity, it is necessary but NOT sufficient.

It is just this kind of input that has been lacking (or systematically rejected) in the design process.

Thanks for your contribution.

/gg

Hi,

On Thu, 2007-11-22 at 08:47 +0100, gg@catking.net wrote:

I find it rather arrogant to presume that those who can code are the only ones who can contribute to development and as a consequence anyone who can code is also an authority on graphic design and UI implementation.

I have never presumed that and I think that this should be very clear from the discussions on this list. You completely ripped my argument out of context and a public apology for this accusation would be proper. Most of your input lately is rather destructive and it certainly not helpful in the process of improving GIMP and its development process.

Sven

On Thu, 22 Nov 2007 08:47:40 +0100, gg@catking.net wrote:

I find it rather arrogant to presume that those who can code are the only ones who can contribute to development and as a consequence anyone who can code is also an authority on graphic design and UI implementation.

You are distorting what Sven said, but this seems to be a rather common perception and complaint so maybe this deserves some clarifications:

Yes, the development of GIMP 2.6 will be mostly developer driven and there will not be much room left for additional suggestions and other stuff that is not already in the list of tasks that we are discussing here. I am not saying that to disappoint you. I am saying that because we have to cope with reality.

Here are some reasons:

- We have far more ideas than developers. We even have far more *good* ideas than developers.

- The development cycle leading to GIMP 2.4 was much too long. It took almost 3 years since the release of GIMP 2.2. The development of GIMP 2.6 should be much shorter so that everybody can benefit from new features and other improvements without having to wait several years between stable releases. But this means that we have to make some hard choices and leave some interesting stuff for later.

- The integration of GEGL and the support for higher bit depths is not a trivial task. Although there were great hopes that GIMP 2.6 would have good support for 16 bits per color channel, fancy color spaces and other features that many users are waiting for, we will not be able to get all of that ready in time. We will make some steps in the right direction, but there will still be a lot of work left for after 2.6.

So what does that mean? We already know at this point that it will be challenging to achieve all goals that are mentioned in the draft roadmap for 2.6. Some of these tasks may seem to be rather obscure and may not bring many visible changes in GIMP 2.6, but they are necessary so that the releases that will follow 2.6 can support higher bit depths (in the core and in the plug-ins) and many other long-awaited features, including some improvements in the user interface.

Considering that we are already struggling with the current list of tasks for which some volunteers exist (there are developers willing to spend some of their spare time working on them), I think that Sven is right when he reminds you that it is not the right time to discuss things that are not in the scope of 2.6 (tasks that are not already supported by a volunteer developer).

-Raphaël

On Fri, 23 Nov 2007 21:38:26 +0100, Raphaël Quinet wrote:

On Thu, 22 Nov 2007 08:47:40 +0100, gg@catking.net wrote:

I find it rather arrogant to presume that those who can code are the only
ones who can contribute to development and as a consequence anyone who can
code is also an authority on graphic design and UI implementation.

You are distorting what Sven said, but this seems to be a rather common perception and complaint so maybe this deserves some clarifications:

I dont agree. He was dismissing Guillermo's comments as just another user's wishlist when clearly Guillermo has and is trying to bring his professional expertise to contribute to GIMP development.

Guillermo has already identified some destructive short comings in jpeg save which led to quite serious and worthwhile improvements to the code.

To dismiss him as just another user and call his posts distracting is disrespectful to his efforts. Not that being dismissive and disrespectful is anything out of the ordinary for Sven.

I recall a week or two ago he spat back a suggestion from Simon as "stupid".

So Sven , before demanding public appologies from anyone learn some respect and good manners towards others. When you feel like appologising to all those you've been offensive with you may like to ask again.

Best regards.

Yes, the development of GIMP 2.6 will be mostly developer driven and there will not be much room left for additional suggestions and other stuff that is not already in the list of tasks that we are discussing here. I am not saying that to disappoint you. I am saying that because we have to cope with reality.

Here are some reasons:

- We have far more ideas than developers. We even have far more *good* ideas than developers.

- The development cycle leading to GIMP 2.4 was much too long. It took almost 3 years since the release of GIMP 2.2. The development of GIMP 2.6 should be much shorter so that everybody can benefit from new features and other improvements without having to wait several years between stable releases. But this means that we have to make some hard choices and leave some interesting stuff for later.

- The integration of GEGL and the support for higher bit depths is not a trivial task. Although there were great hopes that GIMP 2.6 would have good support for 16 bits per color channel, fancy color spaces and other features that many users are waiting for, we will not be able to get all of that ready in time. We will make some steps in the right direction, but there will still be a lot of work left for after 2.6.

So what does that mean? We already know at this point that it will be challenging to achieve all goals that are mentioned in the draft roadmap for 2.6. Some of these tasks may seem to be rather obscure and may not bring many visible changes in GIMP 2.6, but they are necessary so that the releases that will follow 2.6 can support higher bit depths (in the core and in the plug-ins) and many other long-awaited features, including some improvements in the user interface.

Considering that we are already struggling with the current list of tasks for which some volunteers exist (there are developers willing to spend some of their spare time working on them), I think that Sven is right when he reminds you that it is not the right time to discuss things that are not in the scope of 2.6 (tasks that are not already supported by a volunteer developer).

-Raphaël _______________________________________________ Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

You and Sven make some very goods points, however dismissing the suggestions of professional users out of hand is a fairly bad idea, imho. Saying "we cannot accept any new ideas until the existing ones are done" is ok, but just dismissing them out of hand might deny you future access to their expertise (which can be fairly valuable).

Raphaël Quinet wrote:

- We have far more ideas than developers. We even have far more *good* ideas than developers.

One way to reduce idea overload is to have some professional artists who really know how things work and can give really good feedback. This way you're not having a flood from all users. Though in gimp's place it sounds like such people would be more useful for evaluating planned features/improvements then actually coming up with new ones.

Joe

- The development cycle leading to GIMP 2.4 was much too long. It took almost 3 years since the release of GIMP 2.2. The development of GIMP 2.6 should be much shorter so that everybody can benefit from new features and other improvements without having to wait several years between stable releases. But this means that we have to make some hard choices and leave some interesting stuff for later.

- The integration of GEGL and the support for higher bit depths is not a trivial task. Although there were great hopes that GIMP 2.6 would have good support for 16 bits per color channel, fancy color spaces and other features that many users are waiting for, we will not be able to get all of that ready in time. We will make some steps in the right direction, but there will still be a lot of work left for after 2.6.

So what does that mean? We already know at this point that it will be challenging to achieve all goals that are mentioned in the draft roadmap for 2.6. Some of these tasks may seem to be rather obscure and may not bring many visible changes in GIMP 2.6, but they are necessary so that the releases that will follow 2.6 can support higher bit depths (in the core and in the plug-ins) and many other long-awaited features, including some improvements in the user interface.

Considering that we are already struggling with the current list of tasks for which some volunteers exist (there are developers willing to spend some of their spare time working on them), I think that Sven is right when he reminds you that it is not the right time to discuss things that are not in the scope of 2.6 (tasks that are not already supported by a volunteer developer).

-Raphaël

Hi,

On Mon, 2007-11-26 at 22:35 -0700, Joe Eagar wrote:

You and Sven make some very goods points, however dismissing the suggestions of professional users out of hand is a fairly bad idea,

We have this and other mailing-list where developers and artists can exchange their ideas. I am reading through lots of mails and forums each day to find out what GIMP users are saying and so do other GIMP developers. We are receiving a large amount of bug reports and enhancement requests through Bugzilla and we listen to them. We organize events where developers and users meet to evaluate the user requests and to plan the future of GIMP. What's the point of claiming that we would dismiss the suggestions of professional users? I am seriously offended by this accusation.

Sven

It did kindof look that way. And I wasn't meaning to be offensive (certainly I don't support the kind of public attack that other guy is doing) so I guess I was giving unwanted advice; sorry about that.

Good luck on the task list and getting things done for 2.6.

Joe

Sven Neumann wrote:

Hi,

On Mon, 2007-11-26 at 22:35 -0700, Joe Eagar wrote:

You and Sven make some very goods points, however dismissing the suggestions of professional users out of hand is a fairly bad idea,

We have this and other mailing-list where developers and artists can exchange their ideas. I am reading through lots of mails and forums each day to find out what GIMP users are saying and so do other GIMP developers. We are receiving a large amount of bug reports and enhancement requests through Bugzilla and we listen to them. We organize events where developers and users meet to evaluate the user requests and to plan the future of GIMP. What's the point of claiming that we would dismiss the suggestions of professional users? I am seriously offended by this accusation.

Sven