I pushed a fix: https://gitorious.org/mypaint/mypaint/commit/38ada522fd

That should fix both problem 1) and 2), even if only for new ORA files.

I don't think we need a "pickeable" brushsetting, I think the pixops.hpp code handles dynamic erasers/smudging quite well, and had nothing to do with the problem.

I figured out how to reproduce. Select a normal brush, toggle it into eraser mode, then, in mid-stroke, toggle it to normal mode.

This generates a single undo step that does both erase and paint. When you pick the paint, you get an eraser brush.

In some earlier MyPaint version, we had a stroke split for every brush change. There was even a bugreport, because changing the size with the keyboard did trash the undo stack then. While it makes some sense not to split an undoable stroke for every radius change or opacity, we really should split when toggling eraser mode.

At the moment, we don't even split an undoable stroke when you change the brush. So if you start a brush with brush A, then use a brushkey to switch to brush B, the strokemap will record only brush A.

> I think it would be much better to fix that, rather than add user-visible settings for something that is supposed to "just work". I doubt that anyone would really want to tune this brush-by-brush.

It's not only about eraser brushes, but also about blend/smudge brushes (if that makes any difference at all)

> About the last active stroke: we could simply walk through the list of most recent strokes, and examine their brush settings, until we find one that is no eraser.

That's what I first did until Andrew pointed out not-adding eraser-strokes to the stroke-map at all might work better.

> So far I have never seen an eraser brush generate a strokemap

me neither, but haven't had the time to test thoroughly yet.

> In pixops.hpp line 701 there already is code to ignore erasers. Does it not work?

Didn't know that, but it obviously doesn't quite work as it should (or something entirely else fails)

Hm... in general ignoring erasers seems to work, but I just loaded an painting I did, and noticed that I could pick an eraser brush from it (allthough I suspect that the stroke that is highlighted was not actually an eraser stroke).

Do you know a way to reproduce the problem?

Yep, obviously forgot 'not'.
Stroke sounds like a good place to put it in, renaming to stroke_pickable would only be logical then.
Not sure about whether to have this as a visible setting or not, as it won't change often (per brush). For existing brushes, this doesn't make a difference, we'd just have to adjust them once, but what about brushes created from scratch?

OT: What about making brushsettings have a 'boolean' flag to make it possible to display checkboxes instead of sliders? Probably not worth the effort and the loss in simplicity (codewise). And not even the win in UI clarity, as most users won't ever see this. Ah well, doesn't belong here.

Here's a patch which does the following:
Add a brushsetting "pickable". This defaults to 1.0; which means by default all brushes are pickable. However, this does not apply to erasers, which are generally ignored (read: "not added to the strokemap in any case").
As Andrew said, it'd make sense to make smudge and blending brushes not-pickable either (though I'm not sure what the exact criteria might be, as there are for example some blend+paint brushes in the default brushset[s]).
Uh, I added the setting to the "custom" Group, as that was a rather convenient place (for testing). Might make more sense to add a checkbox like the realtime-update-last-stroke one.

(file #14764)

1) pick-context should not pick erasers
2) last-active-stroke (i.e. mypaint uses the last-active-stroke as the startup-brush(-setting) for its next launch) should ignore erasers