Created attachment 109326 [details] example of wrong first stamps If there is some pop-up open (brush editor, brush preset list pop-up, tool options) and you starting to draw on canvas first stamp of the brush will look like with 100% pressure (see pic). It's annoying and I feel ~70% of my undos is this thing. Pop-up pallette seems to lock canvas while it open so clicking on canvas just hide pallette and doesn't create these stamps. I suggest to do same for brush editor and brush preset pop-up.
This is due to the tablet press event being swallowed by the popup. This is under WinTab: [1816] krita.tabletlog: "[ ] TabletEnterProximity" [1816] krita.tabletlog: Start blocking mouse events [1816] krita.tabletlog: "[ ] Enter " [1816] krita.tabletlog: Stop blocking mouse events [1816] krita.tabletlog: "[ ] FocusIn " [1816] krita.tabletlog: "[ ] MouseButtonPress btn: 1 btns: 1 pos: 699, 755 gpos: 776, 889 hires: 776, 889 Source:0" [1816] krita.tabletlog: "[ ] Enter " [1816] krita.tabletlog: "[ ] TabletMove btn: 0 btns: 1 pos: 699, 756 gpos: 776, 890 hires: 776.211, 889.693 prs: 0.603128 Stylus Pen id: 146028888065 xTilt: 0 yTilt: 0 rot: 0 z: 0 tp: 0 " [1816] krita.tabletlog: event latency: mean -3238 ms, var 9, max -3208 ms [1816] krita.tabletlog: Start blocking mouse events [1816] krita.tabletlog: "[ ] TabletMove btn: 0 btns: 1 pos: 699, 756 gpos: 776, 890 hires: 776.211, 889.693 prs: 0.603128 Stylus Pen id: 146028888065 xTilt: 0 yTilt: 0 rot: 0 z: 0 tp: 0 " [1816] krita.tabletlog: "[ ] TabletMove btn: 0 btns: 1 pos: 699, 756 gpos: 776, 890 hires: 776.211, 889.693 prs: 0.624633 Stylus Pen id: 146028888065 xTilt: 0 yTilt: 0 rot: 0 z: 0 tp: 0 " [1816] krita.tabletlog: "[BLOCKED 2:] MouseMove btn: 0 btns: 1 pos: 693, 748 gpos: 770, 882 hires: 770, 882 Source:0" The first events up to the tablet event are sent to the popup dialog: https://phabricator.kde.org/source/krita/browse/master/libs/ui/input/wintab/kis_tablet_support_win.cpp;c34fbd1976b2ca852b170a31ff0e764dd6ccc5b4$810 The tablet press event probably causes the popup to close itself. Meanwhile, the WinTab-generated mouse press event reaches the canvas and painting starts with the mouse, therefore no pressure sensitivity. Subsequent tablet move events gets sent to the canvas because the popup is closed, so pressure sensitivity returns. --- On the other hand, pointer input ignores the whole stroke from pen down to pen up: https://phabricator.kde.org/source/krita/browse/master/libs/ui/input/wintab/kis_tablet_support_win8.cpp;c34fbd1976b2ca852b170a31ff0e764dd6ccc5b4$841 As a result, Windows generates mouse move (pre ver 1709) or touch (ver 1709) events, therefore a full solid line gets drawn. --- Plain mouse and touch will directly draw on the canvas while dismissing the popup. The question is whether we should follow the behaviour of mouse and touch (i.e. send tablet events directly to the canvas), or block the first click for all input while dismissing the popup.
(In reply to Alvin Wong from comment #1) > The question is whether we should follow the behaviour of mouse and touch > (i.e. send tablet events directly to the canvas), or block the first click > for all input while dismissing the popup. I'd prefer to ignore\block the whole stroke because painting with open brush editor probably isn't that useful and accidental move after click-to-close-popup will create unwanted marks on canvas.
Unfortunately I couldn't find a generic way to reliably detect a popup being dismissed. Hooking into the FocusIn event checking `QFocusEvent::reason == Qt::PopupFocusReason` looked promising. However, for some reason I only get that from the application menus but not from the brush setting/selector popups. I thought `QMenu`s are normal widgets with the flag `Qt::Popup` and the brush setting/selector popups are the same?
Hi, radian! This bug has been fixed as part of huge tablet support refactoing we've just had in master. Please check the nightly builds :) https://binary-factory.kde.org/job/Krita_Nightly_Windows_Build/ If you see the problem still persist in the nightlies, please reopen the bug so we could see it in our queries :)