From: Michael Natterer

While doing so I noticed they are all bad and inconsistent.

Here is what I think should happen:

"No brushes available for use with this tool." (brush core) "No patterns available for this operation." (clone)

doesn't matter, these will almost never be seen

"Set a source image first." (source core)

okay

"Indexed images are not currently supported." (heal)

Healing does not operate on indexed layers

"Indexed images are not currently supported." (perspective clone)

Perspective Clone does not operate on indexed layers

"Blend: Invalid for indexed images."

Blend does not operate on indexed layers

"Brightness-Contrast does not operate on indexed layers."

okay

"Color balance operates only on RGB color layers."

Color Balance operates only on RGB color layers ^

"Colorize operates only on RGB color layers."

okay

"Curves for indexed layers cannot be adjusted."

Curves does not operate on indexed layers

"Hue-Saturation operates only on RGB color layers."

okay

"Levels for indexed layers cannot be adjusted."

Levels does not operate on indexed layers

"Posterize does not operate on indexed layers."

okay

"Threshold does not operate on indexed layers."

okay

-- Bill

______________ ______________ ______________ ______________ Sent via the CNPRC Email system at primate.ucdavis.edu

we were discussing a few changes to this on the irc,

On Tue, Sep 26, 2006 at 02:17:34PM -0700, William Skaggs wrote:

From: Michael Natterer

While doing so I noticed they are all bad and inconsistent.

"Indexed images are not currently supported." (heal)

Healing does not operate on indexed layers

Healing cannot manipulate indexed images.

"Indexed images are not currently supported." (perspective clone)

Perspective Clone does not operate on indexed layers

Perspective Clone cannot manipulate indexed images.

"Blend: Invalid for indexed images."

Blend does not operate on indexed layers

Blend does not operate on indexed images.

"Brightness-Contrast does not operate on indexed layers."

okay

Brightness-Contrast cannot manipulate indexed images.

"Curves for indexed layers cannot be adjusted."

Curves does not operate on indexed layers

Curves cannot manipulate indexed images.

"Levels for indexed layers cannot be adjusted."

Levels does not operate on indexed layers

Levels cannot manipulate indexed images.

"Posterize does not operate on indexed layers."

Posterize cannot manipulate indexed images.

"Threshold does not operate on indexed layers."

Threshold does not operate on indexed images.

carol

On Tue, 26 Sep 2006 15:00:16 -0700, Carol Spears wrote:

we were discussing a few changes to this on the irc,

On Tue, Sep 26, 2006 at 02:17:34PM -0700, William Skaggs wrote:

From: Michael Natterer

While doing so I noticed they are all bad and inconsistent.

"Indexed images are not currently supported." (heal)

Healing does not operate on indexed layers

Healing cannot manipulate indexed images.

[...]

I am not sure about "does not operate" vs. "cannot manipulate", but I agree with the usage of "images" instead of "layers": talking about images makes it more likely that the user will think about changing the image mode. In the current GIMP, the mode is a property of the image and cannot be changed for individual layers.

The only exception is if the active drawable is a channel (saved selection) or a layer mask: these are always grayscale so it would not make sense to display a message like "Hue-Saturation operates only on RGB color images" if the image is already RGB. But as I mentioned on IRC, the most likely cause of this warning is that the user is not aware that the active drawable is not a layer. So it makes more sense to add tests like GIMP_IS_LAYER_MASK(drawable) or GIMP_IS_CHANNEL(...) and display a specific message for these cases: "Hue-Saturation does not operate on layer masks" "Colorize does not operate on saved channels"

I'll let the native English speakers decide if "does not operate on" is better than "cannot manipulate", but otherwise I'm ready to add the tests for the layer masks or channels.

-Raphaël

On Wed, Sep 27, 2006 at 03:50:28PM +0200, Rapha?l Quinet wrote:

On Tue, 26 Sep 2006 15:00:16 -0700, Carol Spears wrote:

On Tue, Sep 26, 2006 at 02:17:34PM -0700, William Skaggs wrote:

From: Michael Natterer

While doing so I noticed they are all bad and inconsistent.

"Indexed images are not currently supported." (heal)

Healing does not operate on indexed layers

Healing cannot manipulate indexed images.

[...]

I'll let the native English speakers decide if "does not operate on" is better than "cannot manipulate", but otherwise I'm ready to add the tests for the layer masks or channels.

i thought that using a word that was consistent with the name of the application would be not only helpful for native speakers but also for people translating and non-native speakers.

carol

Hi,

On Wed, 2006-09-27 at 15:50 +0200, Raphaël Quinet wrote:

I am not sure about "does not operate" vs. "cannot manipulate", but I agree with the usage of "images" instead of "layers": talking about images makes it more likely that the user will think about changing the image mode. In the current GIMP, the mode is a property of the image and cannot be changed for individual layers.

I thought that as well. But then I had a second look and it seems that using the term "image" is wrong here. The tools do work on masks and channels in images with indexed colors. They just don't work on layers in such images. But I agree that the term "Indexed Layer" is somewhat strange. But so is the term "Indexed Image". We should probably use something along the lines of "layers with indexed colors".

Sven

Hi,

On Tue, 2006-09-26 at 23:02 +0200, Michael Natterer wrote:

I just comitted a change that moves all tool error messages that can happen when clicking the image to the image window's statusbar, using the new gimp_statusbar_push_temp() API.

How do we handle the statusbar being invisible? Perhaps the statusbar should delegate to gimp_message() if it is not currently shown?

Sven

On Wed, 27 Sep 2006 21:03:30 +0200, Sven Neumann wrote:

On Tue, 2006-09-26 at 23:02 +0200, Michael Natterer wrote:

I just comitted a change that moves all tool error messages that can happen when clicking the image to the image window's statusbar, using the new gimp_statusbar_push_temp() API.

How do we handle the statusbar being invisible? Perhaps the statusbar should delegate to gimp_message() if it is not currently shown?

Yes, but this should probably not be done by the status bar itself. It should be done one level higher so that the code still knows that it is some error message that is important enough to be displayed with gimp_message().

-Raphaël

I'll let the native English speakers decide if "does not operate on" is better than "cannot manipulate", but otherwise I'm ready to add the tests for the layer masks or channels.

"does not operate on" seems like a developer's or mathematician's comment, not language for the end-user who thinks he is using an Image Manipulation Program.

"cannot manipulate" reads much better for me , native english further back than the Queen

(which ain't that far actually. Their family name was Sachsen-Coburg-Gotha until being german became uncool around the early part of the last century and they decided to borrow the name of a castle. ;) ).

On Wed, 27 Sep 2006 23:50:24 +0200, Michael Natterer wrote:

On Wed, 2006-09-27 at 21:25 +0200, Raphaël Quinet wrote:

On Wed, 27 Sep 2006 21:03:30 +0200, Sven Neumann wrote:

How do we handle the statusbar being invisible? Perhaps the statusbar should delegate to gimp_message() if it is not currently shown?

Yes, but this should probably not be done by the status bar itself. It should be done one level higher so that the code still knows that it is some error message that is important enough to be displayed with gimp_message().

We only show messages if things didn't happen as the user expected them to happen. We can't just let user actions on the display fail without any comment. The Statusbar should imho just use gimp_message() if it is invisible.

There are other messages that can be displayed in the status bar but are not errors. In that case, they should simply not be displayed if the status bar is hidden. Obviously that would include the various hints for the tools, selection sizes, guide positions, etc. They don't use the same function call now, so that's fine. But I was also thinking about using gimp_statusbar_push_temp() for something else than errors.

For example, after saving a file it could be possible for the file plug-ins to report things like the size of the saved file, which would then be briefly shown to the user in the status bar. Or if you undo or redo some operation, its name could be briefly shown in the status bar (like in the undo history).

These informational messages would be displayed in the status bar without the "warning" icon that is currently used (we could use some "info" icon although using no icon is probably better if we want the warnings to be noticed easily). And if the status bar is hidden, they would just not be displayed anywhere because they are not very important anyway.

-Raphaël

Raphaël Quinet wrote:

I am not sure about "does not operate" vs. "cannot manipulate", but I

I prefer "operate" to "manipulate". An alternatives would be "can not work with indexed images" or "can not use indexed images"

Hi,

On Thu, 2006-09-28 at 13:30 +0200, Raphaël Quinet wrote:

These informational messages would be displayed in the status bar without the "warning" icon that is currently used (we could use some "info" icon although using no icon is probably better if we want the warnings to be noticed easily). And if the status bar is hidden, they would just not be displayed anywhere because they are not very important anyway.

Sure, I don't think anyone disagrees with that.

It might also help to include the tool icon in the statusbar when a tool displays status or user hints. That would make it clearer where this messages are coming from.

Sven

I hope I'm not showing my lack of UI skills here, but:

On 9/26/06, Carol Spears wrote:

On Tue, Sep 26, 2006 at 02:17:34PM -0700, William Skaggs wrote:

From: Michael Natterer

While doing so I noticed they are all bad and inconsistent. "Indexed images are not currently supported." (heal)

Healing does not operate on indexed layers

Healing cannot manipulate indexed images.

"Cannot heal indexed images. Use Image->Mode to change color mode."

Points: Instructs how to fix the problem. Concise enough (I hope) to fit translations. Remove "Use" if constraints prevent users from seeing "Image->Mode" (the important part) when clipping.

And as a general, pie-in-the-sky, comment:

It seems that indexed mode editing is cumbersome, confusing, and limited. When core operations are moved into a GEGL, The GIMP should probably lose indexed mode editing (indexed formats autoconvert to/from) and a separate tool be created just for this type of editing.

More blue sky:

It would be really slick if all GEGL-apps could shuffle images amongst themselves, assuming that interface is intuitive. So that, for example, an indexed editor, a pixel editor, a SVG editor, and a prepress app could all have a 'window' onto a shared image stored in GEGL space.

Chris

On Sun, Oct 01, 2006 at 12:04:47PM -0400, Christopher Curtis wrote:

I hope I'm not showing my lack of UI skills here, but:

On 9/26/06, Carol Spears wrote:

On Tue, Sep 26, 2006 at 02:17:34PM -0700, William Skaggs wrote:

"Indexed images are not currently supported." (heal)

Healing does not operate on indexed layers

Healing cannot manipulate indexed images.

"Cannot heal indexed images. Use Image->Mode to change color mode."

Points: Instructs how to fix the problem. Concise enough (I hope) to fit translations. Remove "Use" if constraints prevent users from seeing "Image->Mode" (the important part) when clipping.

i think that your rewrite is very good.

it actually causes me to wonder what has happened to humans that we need to have these messages all over the place though. could it be that so many of the 'needs' of users has been fabricated? (fabricated here meaning invented in such a way to make it seem as if there is so much unhappiness and so that it allows something that was really really good to be changed to be not so good)

And as a general, pie-in-the-sky, comment:

It seems that indexed mode editing is cumbersome, confusing, and limited. When core operations are moved into a GEGL, The GIMP should probably lose indexed mode editing (indexed formats autoconvert to/from) and a separate tool be created just for this type of editing.

More blue sky:

It would be really slick if all GEGL-apps could shuffle images amongst themselves, assuming that interface is intuitive. So that, for example, an indexed editor, a pixel editor, a SVG editor, and a prepress app could all have a 'window' onto a shared image stored in GEGL space.

indexing images is used only because a good and free animation format has not been agreed upon or for games or simple graphics for speedy web pages.

perhaps the need to continue to clutter gimp gui is more a failure of all of the communities who are supposedly there adding to the wealth of information that is already known about image manipulation and also about working with GIMP specifically to make images.

how many different ways does the same thing need to be said?

could (perhaps) everyone take a step back and a few minutes to consider that it is actually not possible to make an application that is as strong as GIMP that will work easily for people who will not take the time to become familar with it and get on with something that is more productive.

i will be honest. i do not think that i will ever see that message in the status bar before i will see it in my own mind based on my experience(s).

restated. where are we going? will we want to be there once we arrive?

carol

mitch wrote:

I just comitted a change that moves all tool error messages that can happen when clicking the image to the image window's statusbar, using the new gimp_statusbar_push_temp() API.

I will have to see how this works in practice. I have some doubts as to whether this is a good idea. For myself I'm not that used to looking at the statusbar for tool related messages. I would be concerned whether important messages might be missed if they are only in the status bar. It would also take longer to read messages in the statusbar when the image windows is not wide enough to display the entire message at once. You would have to wait for the message to scroll through the statusbar in order to read all of it compare to seeing it all at once if was in a pop up dialog box.

Hi,

On Mon, 2006-10-02 at 23:56 -0400, Kevin Cozens wrote:

mitch wrote:

I just comitted a change that moves all tool error messages that can happen when clicking the image to the image window's statusbar, using the new gimp_statusbar_push_temp() API.

I will have to see how this works in practice. I have some doubts as to whether this is a good idea. For myself I'm not that used to looking at the statusbar for tool related messages. I would be concerned whether important messages might be missed if they are only in the status bar.

Kevin, these messages are hardly ever shown. They only exist to catch the unrecoverable case where the user tries to do something impossible. We could simply do nothing. After all the cursor already indicates that the tool is not usable.

It would also
take longer to read messages in the statusbar when the image windows is not wide enough to display the entire message at once. You would have to wait for the message to scroll through the statusbar in order to read all of it compare to seeing it all at once if was in a pop up dialog box.

Scroll through? The messages don't scroll.

I think you are making a problem out of nothing here. There are so many important things that we need to figure out before 2.4. Could we try to concentrate on these?

Sven

Good to know that the messages are harddly ever shown and that it isn't anything to worry about since one wouldn't always be able to read the entire message on narrow image windows if they don't scroll.

I just wanted to inquire about it now while the change was fresh. Otherwise someone would be asking why I didn't raise concerns back when it was made instead of waiting x amount of time before raising a question about a change.