OK, should we unify the name to either "shape manipulation tool" like in the action title or "shape handling tool" like the tooltip? I like "shape manipulation tool" because it is more descriptive.

Can you point to an older commit where it was working? A week ago, a month ago? (Note - you need to watch out for Boud's recent JSON thing posted on the mailing list after building older versions of Krita.) My recent tablet patches are supposed to add debugging messages every time they mask events, so I don't think it's that. I'm suspecting this has to do with the XCB support which landed 3 weeks ago in rKRITAba65b1f.

What happens when you turn on the tablet logger with Ctrl+Shift+T? You should see a bunch of events in stdout like:

Looks like a null pointer to a QWindow. Probably can be fixed with a judiciously placed if (targetWindow == 0) { break; }

It works on my systems, can you give any more details? Do the +/- shortcuts work?

Cool! The step size does get saved, and the tool remembers the previously selected unit as well. I think that may be nicer than resetting to pixels each time.

This seems to have cleared up.

Allow setting different units of measurement

Fix

Make step distance configurable

Remove qDebugs()

I got a random crash on Windows when making a selection recently, I bet it is due to the same issue.

I pushed a few patches. I will keep this task open and change the description to keep track of other bugs.

The "configure shortcuts" stuff could get messy I think, because it relies entirely on the Qt event system. You'd have to generate some custom Qt events that the ShortcutEditWidget could capture, and annoyingly if you want to keep the same configuration options, you'd have to do some serialization/deserialization that extends QKeyboardShortcut. The whole thing is not very fun to work with anyway because it's sort of a mish mash of KDE's XMLGUI and Krita's custom system. It's also limited to managing QActions and their metadata. Finally, writing this part is probably the least important part because another option exists already: just bind your joystick buttons to unused combinations like Ctrl+Shift+F1..Ctrl+Shift+F12 in the joystick driver, then bind the keyboard combos separately in Krita. So that part of the project is really more icing on the cake than core functionality.

This is awesome, thanks so much for putting it together.

I haven't used the Linux builds recently, usually full-pressure splotches are generated by mouse events which aren't properly blocked. If you could capture the behavior with a tablet event log that would be the best way to target a fix. An alternative is to add some sort of filter to determine whether an event looks out of place and discard it.

Yuck, happens deep down in OpenGLFunctions...

Does rKRITA60dd28703ed3 fix the problem?

Is this canvas inputs or the new shortcut schemes?

Cool, I was just curious. Ship it! ✔️

This latest update is not implementing any new features, just fixing the old patch and enabling pressing "E" to switch devices.

Fix eraser handling

OK, great! I do have one question though, do we want to create the rand_dev, rand_engine and rand_distr as class members instead of instantiating them at the time of the function call?

In D549#12348, @Deevad wrote:

Well, after thinking and reading, my opinion moved to this 'classic' mockup:

E key = toggle switch to this second Freehand eraser
{unassigned} = toggle to 'Erase blending' mode.

In D549#12347, @timotheegiet wrote:

That could potentially work, though I'd prefer to have both use modifier-free shortcuts.

Keeping shortcuts mnemonic is also worthwhile, though. I think there are many other things that should take priority for Krita's top level shortcuts. (See T948)

In D549#12344, @woltherav wrote:

Don't forget the toolbar can be customised. So we can have two actions with the same icon, and the user switches the one in they need?

In D549#12341, @timotheegiet wrote:

@abrahams:
when you say "Telling users to use previous paintop as a replacement for the eraser is in contradiction to points 1 and 3 I've made above", I think you misunderstood what I proposed.

What I meant is: for the / key, replace the "previous preset swicth" shortcut with this "switch to eraser tip preset (and tool)" (or a virtual one for users without an eraser tip).
As far as I understand this is what you did, just to me it makes more sense to make it replace the old confusing / shortcut instead of replacing e.

To me, both switching current preset to erase mode (and potentially different size) and switching between two paint devices (what I called slots..) are useful and I want users to have both accessible by default, not have to choose between one or the other. Both deserve a button in the toolbar and a default shortcut.

With schemes support, we can provide a "PS-style defaults" scheme to aid the transition.

Thanks for the input @timotheegiet and @Deevad. I'll share my own thoughts about the method.

There does seem to be something wrong with the eraser mode when using the mouse only, I will update with fix when I figure it out.

In D549#12249, @rempt wrote:

Hm, I just tested with just a mouse, and pressing E does change the erase button, but not the blending mode, and it also doesn't select an eraser preset, so nothing really changed.

In D549#12261, @timotheegiet wrote:

Hi,
I have a big problem with this proposal:
Quickly alternate between normal and erase mode for the same preset is a very important part of the workflow I use and teach.
And while you've heard some users complaining, I've heard a lot that were very happy to can do this.

So please, don't remove that feature! Either make it an option (not activated by default) to select a user-defined eraser preset instead.

Or even better, if we had a way to assign shortcuts to presets, that would solve this usecase and several others at the same time.

Closed by string of commits ending with rKRITAe4ce23bbc07