If I remember correctly this behavior is intentional. We want to avoid that the tool simply does nothing. If the user uses the erase tool, then she most probably wants to edit the alpha channel so we silently override the lock. This behavior is perhaps not 100% correct but it improves usability by eliminating a source of confusion (see bug #421434).

Can you imagine a use case where this behavior gets into the way somehow? Otherwise we should close this as NOTABUG.

Exactly what is the difference between this bug and bug #445557?

It was not opened by Carol. If it had been opened by her, we would have closed it as INVALID as we don't accept any bug reports from Carol nor do we want any other contributions from her. She is not welcome in the GIMP project any longer.

All is well as long as the user does realize that she is changing the layer. You might be working with low opacity or maybe on an invisible layer, though.

Additionally, is it planned to ingore a possible future "pixel" lock for the paintbrush and other tools, too? Should any lock only work for non-tool changes?

You have a point. Perhaps it's better not to start making exceptions.

In my opinion, the real problem is to tell the user why a tool does not have any visible effect. I think Peter and Kamila will be interested in this, thus adding usability keyword.

I agree with Michael,

first I was sympathetic to the 'erase overrides alpha lock' position, but there are situations where the user intention of 'do not mess with this layer's alpha' should simply be followed.

like several layers linked, some of them alpha locked, some not. apply the eraser.
make an exception to the eraser exception?

as Sven said: "Perhaps it's better not to start making exceptions." I agree.
so back to solving the "tell the user why a tool does not have any visible effect."

dialogs are not the solution. very, very annoying.

here is mine: when there is such an absolutely zero data change situation, when the erase tool is applied to the image (on mouse down), a BIG text is displayed on the image, under the mouse: "Alpha channel locked". mouse up: text disappears. at the moment I would use invert for the text, later on this would be a HUD, when we have that technology.

this UI pattern could be reused for other tools in absolutely zero data change situations.

Comment #7 rather belongs to bug #421434.

We already have tools that change their cursor image when some operations are impossible.  Consider for example the clone tool or healing tool using GIMP_CURSOR_MODIFIER_BAD when no source is defined, or the move tool using that same modifier when the cursor is over a fully transparent area.  A similar solution could also be used for the eraser.

If we want to complement the indication given by the cursor with some text message giving hints about how to solve the problem, I would go for a simple status bar message.  That combination of cursor modifier + status bar message is much less intrusive than a big warning under the mouse and is also more consistent with how other tools behave when some operation is impossible.

hmmm,

intrusive is what we need here, because it is an 'absolutely zero data change situation,' so actually nothing else happens at that moment. the situation needs to be resolved by the user, and we have to do everything to get that started.

when applying a tool to an image, users will be focussing on an incredibly small part of the screen, exactly because they are doing a precision job in a concentrated way.

so our only chance to do a good job here is to use that 'small part of the screen,' not in the statusbar.

also I want this message to appear only when the situation really appears, on mouse-down in the image. in other cases (select the tool first, the go to the layers dialog to set up the layers) I do not want any warnings.

BIG, clear, appears only when needed and clears by itself fast. these are the qualities I look for to make a decent solution in these cases.

progress means changing things compared to the past. else the streets would still be full of original volkwagen beetles. that was a perfect family car, in the 1950s. unacceptable to most today...

I disagree with the need for intrusive messages.  Consistency is more important here.  We already have several tools using the same indication when some operation is not possible (GIMP_CURSOR_MODIFIER_BAD + a message in the status bar).  Besides the examples mentioned in comment #9 (clone tool, healing tool, move tool), this is also the case for the blend tool when it is used over an INDEXED image, for the flip tool or transform tools when there is nothing to transform (e.g., mode set to paths, but image contains no paths), for the iscissors tool when it is waiting for you to convert to a selection, and probably in some other cases that I forgot.

Some of these cases can depend on the position of the cursor over the image and can change quickly.  For example, if the only visible layer in your image is a text layer (many transparent areas), then using the move tool and moving around the text will probably make it toggle several times between the "possible" and "impossible" states (GIMP_CURSOR_MODIFIER_BAD) until your cursor is correctly over the text (non-transparent area that can be grabbed for moving).  It would be very annoying to have an intrusive warning showing up and disappearing several times while you are trying to adjust the position of the cursor for moving the text.  The non-intrusive indication given by the cursor modifier does not break the flow.  

If we want to have some consistency accross all tools, then the type of indication given when an operation is impossible should be the same for all tools.  The current solution used by the other tools is sufficient and not too intrusive, so it should also be used for the eraser.  As you wrote, the user is focusing on a small area so he will notice the sign added to the cursor.  If he does not know why this happens (i.e., if he has not encountered a similar situation before), then he can look at the status bar for a description of the reason.  This extra message is not even needed in all cases, because in some cases the reason should be obvious so we only need to change the cursor to inform the user without adding other disturbances.

If a cursor change and a status bar message was good enough to inform the user, I would be in favour of it because it is the most practical thing to do.

But it is simply not good enough in the case of erase on locked alpha layers . And that is why I cannot endorse it as a solution.

Many factors go into a consistency decision, every little detail counts to decide if you are dealing with the same situation that needs the same solution, or whether this is a new situation that needs a new decision.

Look for instance at "Some of these cases can depend on the position of the cursor over the image."
That changes the game, and what I do then is take a new decision, to be consistently applied to all
these cases with the same conditions.

The number of clauses and edge cases in comment 11 show that one blanket rule for dealing with them does not work. Going through these situations and ending up with an optimised list of, two, three or
four different UI responses, that in each case get users to understand the situation and back to work, is simply a matter of sitting down and do it, it is my daily work.

I am really wondering what makes you think that it is not good enough for this specific case while it is good enough for the other cases mentioned above.  From my point of view, a change in the cursor (+ an optional status bar message) is sufficient and would lead to a better user experience.  But maybe we should talk about this on irc or on the mailing list in order to avoid long discussions in bugzilla.

Can you please respect comment #8 and move this discussion elsewhere? This bug report is about the misbehavior of the eraser tool, not about how to inform the user that erasing is not going to have any effect. Your discussion belongs to the bug report pointed out in comment #8. Or even better, move it to the mailing-list please.

See also bug #486902 for a different approach.

Lock alpha is handled generically in git master (with gegl) so this
bug is fixed. Let's wait until somebody notices and files the new
behavior as bug ;)