Overview: In Krita 3.3.3, if I use one of my Wacom pen buttons to right click - I will occasionally have a pen get selected automatically (if the spot I'm right clicking happens to correspond with a pen in the selector). Note: In Krita 3.3.2, I never get a pen automatically selected. Reproducible: Always Steps to reproduce: 1) Right click on the canvas with one of the pen buttons on the Wacom Pro Pen 2. Make sure that the spot you're right clicking corresponds with the location of one of the pens that pop up. 2) The window will disappear before you can do anything with a new pen selected. Actual results: The pen will get automatically selected. Expected results: The pen selector modal will remain open so I can select things like other pens or colors. Build: Krita 3.3.3 (downloaded from the Microsoft Store so should always be up to date). My manual download of Krita 3.3.2 from the krita.org website does not have this issue. Please let me know if you need any other information. This bug is somewhat difficult to describe so I'm hoping this makes sense.
Thanks for the clear report. I can confirm the issue though I wonder if it's by design. (Tested on Ubuntu 14.04 with Krita 4.1.0 pre-alpha appimage)
I think it might have been by design. I believe it behaves this way so that one can hold the stylus button and drag to switch the brush preset without needing to make an extra click. Though it could also be an unintended effect. Are you using the Pointer Input (Windows Ink) tablet support? There was a change in behaviour from v3.3.2 to v3.3.3 which was supposed to fix some inconsistencies with the WinTab tablet support.and this is one of them. If you are using WinTab though, it should also happen on v3.3.2 and it wasn't changed in v3.3.3.
(In reply to Alvin Wong from comment #2) > I think it might have been by design. I believe it behaves this way so that > one can hold the stylus button and drag to switch the brush preset without > needing to make an extra click. Though it could also be an unintended effect. > > Are you using the Pointer Input (Windows Ink) tablet support? There was a > change in behaviour from v3.3.2 to v3.3.3 which was supposed to fix some > inconsistencies with the WinTab tablet support.and this is one of them. > > If you are using WinTab though, it should also happen on v3.3.2 and it > wasn't changed in v3.3.3. I am indeed using the Windows 8+ Pointer Input (Windows Ink). I can definitely see why this could be one of those things considered to be a "feature" instead of a bug from your explanation. I guess I just got used to the old workflow of always just tapping the right click on my pen and then thinking about what thing I wanted rather than having to hold and drag. I can always re-position my drawing or just get used to the new standard if that's by design (although it would be great if this was customizable - but I definitely don't see this as a high priority feature request by any means). Thanks for the input :)
This exists for a long time on Linux as well, and is still present in current 4.0 master as of today, using the kernel drivers. (Sorry I kept forgetting to report it.) This also causes context menus to operate in a "hold and release to select" manner, which I thought to be intentional. Additionally, when using the context menu in the layers docker, if I move the cursor over one of the layer color swatches as I hold right click to navigate the menu the color gets selected even if I just pass over it without releasing. Conclusion: This behavior makes using popup palette and menus very painful, so even if it's intentional, please change it or make it optimal.
This is interesting, I just closed a bug I reported of this issue thinking I was the only one experiencing it (https://bugs.kde.org/show_bug.cgi?id=375073), I guess its perceived in different ways. Now I also think that Tyson was referring to this same issues in (https://bugs.kde.org/show_bug.cgi?id=378484), thus I seen these as duplicate of that report since Tyson's is confirmed.
The popup palette behaviour appears to be a special case as I recall that it is invoked on a tablet press-with-side-button event, instead of a mouse right-button down/up event. As a result, the actual (synthesized) mouse press event gets sent to the popup palette and thus the following mouse release event can trigger a brush preset selection. Putting it this way, it does seem to be an unintended behaviour of how the popup palette works. It doesn't happen with a mouse right-click. (In reply to Storm Engineer from comment #4) > This also causes context menus to operate in a "hold and release to select" > manner, which I thought to be intentional. I was about to say that this doesn't happen, but then I realized it does happen with the context menus on the canvas when using certain tools. It does seem to be intentional because it also happens when using a mouse. Other context menus (on layers docker and others), however, only pops up on a right-mouse-button release event, at least on Windows. I don't see a problem with them This commit seems relevant: https://github.com/KDE/krita/commit/259d5f8253da02717ca5e985e0b979c8a15e3165#diff-aab2f60d332f75c298562b5349d57039
*** Bug 375073 has been marked as a duplicate of this bug. ***
(In reply to Alvin Wong from comment #6) > it also happens when using a mouse. I can confirm. I never noticed.* > I don't see a problem with them Using the menus and palette with my Wacom pen is very frustrating and sometimes outright painful. Constantly selecting things I don't mean, constantly picking brushes and colors when I just want to open the palette. And most importantly it makes no sense since the side button is set to be a right click - why is this right click behaving entirely different from my mouse right click? * The huge difference is that a mouse cursor generally stays in the same place as you click - a pen held hovering over the tablet is unstable, so it's very easy for it to move over to the first option before you release the button, by accident. I believe press and hold only makes sense in the case of touch and should not be default for anything with buttons (eg stylus/pen, mouse, trackball, touchpad buttons, etc.) Touch and hold could be a great _optional_ feature for the minority who own and use a touch enabled device, but shouldn't be default behavior, especially when not even using touch.
(In reply to Storm Engineer from comment #8) > (In reply to Alvin Wong from comment #6) > > > I don't see a problem with them > Using the menus and palette with my Wacom pen is very frustrating and > sometimes outright painful. Constantly selecting things I don't mean, > constantly picking brushes and colors when I just want to open the palette. > > And most importantly it makes no sense since the side button is set to be a > right click - why is this right click behaving entirely different from my > mouse right click? > > * The huge difference is that a mouse cursor generally stays in the same > place as you click - a pen held hovering over the tablet is unstable, so > it's very easy for it to move over to the first option before you release > the button, by accident. > > I believe press and hold only makes sense in the case of touch and should > not be default for anything with buttons (eg stylus/pen, mouse, trackball, > touchpad buttons, etc.) > > Touch and hold could be a great _optional_ feature for the minority who own > and use a touch enabled device, but shouldn't be default behavior, > especially when not even using touch. When I said this, it was referring to the context menus in other areas: > Other context menus (on layers docker and others), however, only pops up on > a right-mouse-button release event, at least on Windows.
(In reply to Alvin Wong from comment #9) > When I said this, it was referring to the context menus in other areas: Oh sorry, I misread it, my bad.
Git commit c7e6c0184f951b4b4165a4bbb7e99107a9e36cb0 by Dmitry Kazakov. Committed on 18/04/2018 at 14:27. Pushed by dkazakov into branch 'master'. Disable right-clicking on popup palette With this patch it is not possible to select a palette item using the right-click of the stylus. All the distinct actions should be confirmed with the left button. Right-click on any part of the canvas just closes the entire palette. Related: bug 378484 M +24 -1 libs/ui/kis_popup_palette.cpp M +5 -0 libs/ui/kis_popup_palette.h https://commits.kde.org/krita/c7e6c0184f951b4b4165a4bbb7e99107a9e36cb0
Git commit 93e1e39386eae6b23b390ab7c3034c83f864a7ec by Boudewijn Rempt, on behalf of Dmitry Kazakov. Committed on 02/05/2018 at 11:54. Pushed by rempt into branch 'krita/4.0'. Disable right-clicking on popup palette With this patch it is not possible to select a palette item using the right-click of the stylus. All the distinct actions should be confirmed with the left button. Right-click on any part of the canvas just closes the entire palette. Related: bug 378484 (cherry picked from commit 20c9efffb70cf2757595fee8d7c56a5fe59d5664) M +24 -1 libs/ui/kis_popup_palette.cpp M +5 -0 libs/ui/kis_popup_palette.h https://commits.kde.org/krita/93e1e39386eae6b23b390ab7c3034c83f864a7ec