| Summary: | [WACOM] Map stylus buttons as modifiers | ||
|---|---|---|---|
| Product: | [Applications] krita | Reporter: | Kyle UX (chez Tinderbox) <krita> |
| Component: | Tablets (tablet issues are only very rarely bugs in Krita!) | Assignee: | Krita Bugs <krita-bugs-null> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | CC: | dadapotok, halla |
| Priority: | NOR | ||
| Version First Reported In: | 2.9.4 | ||
| Target Milestone: | --- | ||
| Platform: | Microsoft Windows | ||
| OS: | Microsoft Windows | ||
| URL: | http://tinderboxentertainment.com/krita/wacom_eraser.png | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Kyle UX (chez Tinderbox)
2015-07-13 07:59:34 UTC
Hm, that's actually not as straight-forward as it sounds. Unless wacom when you map the eraser to the thumb switch actually switches the unique id of the stylus tip end to the id of the eraser tip end, this isn't going to work. Krita remembers which brush preset is associated with which end of the stylus -- so you can for instance map a smudge preset to the eraser end. What you could try to do is map the switch to the 'e' key which toggles erase more on and off. Thank you for the response! I love Krita and want it to be the best so I can switch my team over to using it professionally. Mapping the switch to 'e' is exactly what I did, but it's less than ideal. For example, when I click the switch to toggle the eraser, sometimes the stylus is outside the range of the screen sensors. Thus, may not engage. The only visual feedback I get as to weather or not the eraser has engaged is way up in the upper left of the toolbar. Of course that is not where I'm looking when I draw so when it doesn't toggle I end up painting instead of erasing. With the method I'm trying to achieve, there is no need for visual feedback because if I press the switch, I know it's the eraser. I suppose another option would be to have a key binding for the eraser toggle that when pressed would toggle to the eraser mode, then toggle back to brush when released. Then I could map that key to the toggle. I assume this solution could all be done within Krita code and you wouldn't have to touch the Wacom API. But I feel it's more of a workaround. I'm not sure I completely understand the technical details, but every other paint program I own is able to map the eraser command to the switch; so when the switch is pressed, then the tip touched to the screen, it erases. And it looks like Krita does half this. It switches to the eraser, but the then the tip does nothing. Again, thanks for the reply. Please let me know if I can help in any way. Beyond general stability, this is the only feature preventing us from using Krita as the default pixel-pusher studio wide. Thank you for such a great product! Well, we're hit by our flexibility here. In other apps, an eraser is a tool, in Krita it's either a blending mode or a brush preset. That has advantages and disadvantages, of course. It's way more flexible, but it also means a different workflow. One thing we're looking into is creating a map of shortcut keys to specific presets, and that would solve this problem. Associate a shortcut with an eraser preset and map that to the stylus button and presto... We're not done with that yet, though! Yeah, assigning presets would probably work great. We'll be eagerly awaiting the feature. Thanks! After thinking about it further. Binding a shortcut key to preset would probably only work if there are options for "Key Pressed" & "Key Released" on that shortcut. So when that key is in the down position: use the eraser preset. And when it is released: use the previous preset. Then one could map the shortcut key to the switch in the Wacom panel. Would that be a possible feature? Same issue with Wacom tablet Intuos Pro on mac os - sometimes eraser won't work, sometimes it works. Somehow turning Open GL view on and off helped to enable it, or it is just a coincidence Yes, having a kind of modifier shortcut that be bound to the stylus button would be a good thing to have. Hm, dmitry says he fixed it once, but it might be broken again. *** This bug has been marked as a duplicate of bug 337135 *** |
