Normally Krita can remember two brush settings individually for the stylus tip and the eraser tip. However, in the recent git-master builds, the brush system mixes up the settings when I switch between stylus and eraser. I have encountered all sorts of weirdness that cannot be generalized in a sentence. Reproducible: Always Steps to Reproduce: 1. Open Krita 2. Use the stylus tip of the pen, select brush "ink_circle_10". This is a thin, pressure respected brush. Pick color pure red to see better. 3. Draw using the stylus tip with brush "ink_circle_10". Works fine. 4. Now flip the pen to use the eraser tip. select "eraser_hard". This is a thick eraser brush that does not respect pressure. Very easy to distinguish between "Ink_circle_10". 5. Erase using the erase tip with brush "eraser_hard". Works fine. 6. Flip the pen back to stylus tip, now the brush setting become something like "eraser_hard" with eraser mode OFF. 7. Flip the pen back to eraser tip again. The eraser mode is not kept. The brush settings feels wrong, too. Actual Results: After assigning two different brushes to the stylus tip and the eraser tip, switching between two tips mixes brush settings up. Expected Results: Krita should remember brush settings for the stylus and eraser tips individually. Switching between the two tips should not mix up the brush settings. A very similar bug was introduced when Krita 2.8 got a whole new brush set. I didn't report back then because I was very busy. A few days later the bug was somehow fixed. Now it returned, probably after revision 16a8d275.
Animtim confirms.
Still present in master. You need to flip several times to see the weirdness. For me stylus->eraser->stylus->eraser will lead to Eraser Mode disabled.
I've tried again, and I still cannot reproduce :-(
Seen a similar problem on 2.8 Pre-Alpha, on Windows 7: http://www.youtube.com/watch?v=glL85gEaZS0&feature=youtu.be You can see that I use a small pencil, then switch to the soft eraser (by flipping my Intuos 3's stylus) which draws instead of erasing. When I raise the stylus' eraser and then touch the tablet again, the eraser works as it should. Please let me know if you'd rather have a separate bug as I'm on a different platform or if you need any clarification.
*** Bug 330172 has been marked as a duplicate of this bug. ***
It looks as if the signal that changes the composite op comes later than the user starts the next stroke. I cannot reproduce the real weirdness which I saw before, but still there is another bug: if you flip the pen too fast, your first stroke will be started before the composite op has been changed and you will paint instead of erasing. And yes it is applicable to the first stroke after the flip only.
Ok, on Windows the bug still persist. The main condition for a bug: 1) Paint with one side of the pen 2) Leave the proximity 3) Flip the pen somewhere in the air 4) [very fast] Bring the pen into proximity and start painting. The composite op doesn't manage to change in time so the first stroke is done in old Composite Op. Also on Windows after several attempts to reproduce that Krita gets crazy when trying to paint with eraser and changes the composite op randomly.
On Linux I didn't manage to make Krita crazy, probably, it is windows specific. So we have two bugs here: 1) Race condition on Composite Op when flipping the pen too fast (Linux + Windows) 2) Krita gets crazy in some time, by sticking to one specific tip of the pen. That results in Krita switching back to, say, Eraser of the pen as soon as you leave proximity with the Pen tip. That is is switches back to a specific tip when you leave proximity of the device.
@Dimitry I happened to reproduce something similar to Comment 7 yesterday using build from 2.8 branch source. 1) Pen tip was assigned to default brush. 2) Pen eraser was assigned to "Basic Eraser" present. 3) I filpped my pen quite prequently. 4) Suddenly, I found I was drawing with "Basic Eraser" on the pen tip. And I was using a Trisquel GNU/Linux 6.0 (a Ubuntu 12.04 derivative), so I think this might not be Windows specific. Although comparing to the original state when I reported this bug, it has been improved somehow that I haven't see it for quite sometime. When I encountered this yesterday, I totally forgot I had reported this bug before. :b
Git commit 36950b6e5f4a1340ec93f97d8384c1d430b4704f by Dmitry Kazakov. Committed on 02/02/2014 at 12:25. Pushed by dkazakov into branch 'master'. Fixed the half of the Pen/Eraser flip bug We should call the update slot explicitly when changing the paintop preset and do not rely on the widgets, which would also emit the update signal, but later. We can't wait for widgets because they use a deferring timer internally. Now it is left to fix the Windows-only problem. M +7 -0 krita/ui/kis_paintop_box.cc http://commits.kde.org/calligra/36950b6e5f4a1340ec93f97d8384c1d430b4704f
The brush settings do not mix up on Windows now, but it still switches back to a random tip of the stylus when the stylus is outside the proximity. This prevents configuration of the stylus using the mouse. To reproduce the bug you need to switch windows with a stylus at least once.
Git commit 6f7ac56db4b71f54cbd737a3f0781fd2c4676600 by Dmitry Kazakov. Committed on 02/02/2014 at 14:35. Pushed by dkazakov into branch 'master'. Don't eat WinTab Proximity packets from the WinTab's queue! Qt also needs these packets to issue the Enter/Leave events. So just use the *Peek variant of the function instead of *Get. M +5 -2 krita/ui/input/wintab/kis_tablet_support_win.cpp http://commits.kde.org/calligra/6f7ac56db4b71f54cbd737a3f0781fd2c4676600
Git commit ef2bcf8e3c27f58003089f87dcf829d48840139c by Dmitry Kazakov. Committed on 02/02/2014 at 12:25. Pushed by dkazakov into branch 'calligra/2.8'. Fixed the half of the Pen/Eraser flip bug We should call the update slot explicitly when changing the paintop preset and do not rely on the widgets, which would also emit the update signal, but later. We can't wait for widgets because they use a deferring timer internally. Now it is left to fix the Windows-only problem. M +7 -0 krita/ui/kis_paintop_box.cc http://commits.kde.org/calligra/ef2bcf8e3c27f58003089f87dcf829d48840139c
Git commit d7d768aba09499428bbc7766d00743d7764c67fe by Dmitry Kazakov. Committed on 02/02/2014 at 14:35. Pushed by dkazakov into branch 'calligra/2.8'. Don't eat WinTab Proximity packets from the WinTab's queue! Qt also needs these packets to issue the Enter/Leave events. So just use the *Peek variant of the function instead of *Get. M +5 -2 krita/ui/input/wintab/kis_tablet_support_win.cpp http://commits.kde.org/calligra/d7d768aba09499428bbc7766d00743d7764c67fe