Okay, hopefully fixed in a way that's right for all use cases:

https://gitorious.org/mypaint/mypaint/commit/a22e286b279e

Behaviour of "x" history during a stroke:

• In a continuous movement with the pen held down, pressing "x" toggles between the colours which are found at hist[-1] and hist[-2] at the start of the movement.
• If the pen is held in one position while strokes are being laid down, and "x" is pressed repeatedly, the entire history is cycled through.

This is the desired 0.9 behaviour, I think. Behaviour of the Colour subwindow's display of the most-recently painted colour:

• When a stroke is split for any reason (e.g. after the end of an input stroke plus a small amount of time and a motion-notify event, or during a long stroke's motion-notify events), the brush colour at the split point is pushed onto the end of the history.
• The user pressing "x" in the middle of a long stroke is a special case of the above: it splits the model stroke, starting one with a new colour.
• When the user finishes a drawing action with pressure, the brush colour is pushed onto the end of the history. It doesn't matter if this happens outside the window because we receive the button-release event anyway due to the implicit grab.

This is two callbacks related to the end of a drawing action with pressure, not one, but neither is redundant. The first is required for correctness with zero-pressure splatter brushes and within strokes; the latter is required for UI responsiveness. We perform de-duplication on the history, so it should be fine.

The colour selectors' last-painted colour is no longer updated correctly. To reproduce:

1. Pick a new colour using the "Colors" subwindow

2. Paint with it, release mouse button

3. Waft the pointer about a bit to make sure the model stroke is split by a timeout

Deviations from expected behaviour:

i. The right-hand colour in the "Colors" subwindow's "Newly chosen color, the color most recently used for painting" control and is not the color just painted with.

ii. The last-painted colour only updates after the model stroke is split, necessitating step 3. It should update immediately because stroke splitting != input stroke ending. This discontinuity makes the app feel jarringly clunky or unresponsive, particularly if the input stroke ended outside the window: in this case, because the stroke is only split when the pointer re-enters the canvas and makes an ungrabbed motion-notify-event, and because it could potentially be minutes or days before that happens (what if the user puts their pen down and goes for a cup of tea?), there might be a jarring on-screen update which seems to have no reason.

I suspect both are caused by https://gitorious.org/mypaint/mypaint/commit/d9474e693762e2c5a583c62077697e02052ecbb9

For ii., I understand that we want to update the colour history when the user puts pixels on the canvas with a brush that requires no pressure, like a splatter brush. So I see why the input stroke observer idea is not being used - however I think it should be. In addition to what we now have, for reasons of GUI responsiveness.