Summary: | weird ui behaviour using scroll wheel while hovering over brush settings editor | ||
---|---|---|---|
Product: | [Applications] krita | Reporter: | Tom Hall <tahall256> |
Component: | Usability | Assignee: | Krita Bugs <krita-bugs-null> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | halla, sven.langkamp |
Priority: | NOR | ||
Version: | git master (please specify the git hash!) | ||
Target Milestone: | --- | ||
Platform: | Compiled Sources | ||
OS: | Linux | ||
Latest Commit: | http://commits.kde.org/calligra/ba940db3eef1b640276d49c1341f3d52d0684491 | Version Fixed In: | |
Attachments: |
Image showing bug.
Proposed workaround |
Description
Tom Hall
2012-06-29 22:00:30 UTC
Created attachment 72224 [details]
Image showing bug.
N.B. Bug occurs both when brush settings popup is attached to, and detached from the toolbar.
I can't reproduce. Is this bug reproduceable? If could you make a video it? Video here: http://www.youtube.com/watch?v=yO2oTUCz-GQ Yes, I can reproduce. I think this is a side-effect of Arjen's new interaction framework, some event handling seems to be broken. Hm... Impossible to say for sure whether this is a regression since 2.4 never had more options than would fit in the brush preset editor! But I'm beginning to believe it hasn't got anything to do with the interaction framework. We made a few observations when investigating this bug. It happens only when mouse and tablet are plug in at the same time. The widget switch is cause by tablet event that is send at the same time as the mouse event from the scrolling, which leads to to a switch of the input device. The bug also only happens if the settings popup is attached to the toolbar. Created attachment 80043 [details] Proposed workaround After further investigation, I have found a workaround that seems to 'fix' this bug's symptoms. The problem seems to stem from a stream of ~8 spurious 'tablet' events. These events have QtabletEvent::NoDevice, QTabletEvent::UnknownPointer, and a unique ID of 0. Despite being apparently similar, they are not caught by the line (KoToolManager.cpp:637): if (inputDevice == device) return; However, due to a workaround in KoInputDevice::isMouse(): bool KoInputDevice::isMouse() const { // sometimes, the system gives us tablet events with NoDevice or UnknownPointer. This is // likely an XInput2 bug. However, assuming that if cannot identify the tablet device we've // actually got a mouse is reasonable. See https://bugs.kde.org/show_bug.cgi?id=283130. return d->mouse || d->device == QTabletEvent::NoDevice || d->pointer == QTabletEvent::UnknownPointer; } we can apparently treat the 'tablet' events as mouse events. Therefore, by simply checking if we are switching from a mouse to a mouse (and returning if we are), we avoid switching input device through a series of non-existent 'tablets', which ultimately triggers the behaviour described in this bug (I suspect the really weird stuff is the result of some sort of race condition when it attempts to switch to several non-existent devices, more or less simultaneously, and some of them try to load the settings for different brush engines). Possible problems with this patch: - 2 mouse devices: As far as I'm aware, a mouse is a mouse is a mouse, and X can't distinguish between events from 2 mice anway, but if it can, then this patch would prevent switching between them. - What if Krita gets stuck with a fake tablet-mouse as the inputDevice, and cannot switch to the real mouse because of the if-statement? I haven't yet observed any such unusual behaviour using the patch, but I haven't been able to test exhaustively. Ultimately, I would prefer to work out exactly where these events come from and deal with them there. However, I haven't been able to track them down yet. It has been observed that: - The tablet has to be plugged in to reproduce the bug. - They aren't 'real' tablet events, in that the stylus is not anywhere near the tablet. It may also be illuminating to review the situation in the light of Bug 283130, which now appears to be a different side-effect stemming from the same core issue as this one. Patch looks good to me, I don't know how I came to miss it... Git commit ba940db3eef1b640276d49c1341f3d52d0684491 by Sven Langkamp. Committed on 26/09/2013 at 19:03. Pushed by langkamp into branch 'master'. workaround for weird ui behaviour using scroll wheel while hovering over brush settings editor patch by Tom Hall M +1 -0 libs/flake/KoToolManager.cpp http://commits.kde.org/calligra/ba940db3eef1b640276d49c1341f3d52d0684491 |