Hovering over various widgets in the Brush Settings popup and using the scroll wheel on the mouse can produce some very strange behaviour. This is a particular example that I have worked out how to reproduce: Reproducible: Always Steps to Reproduce: 1. Open the Brush settings 2. Select the pixel brush 3. Select another brush 4. Select the pixel brush 5. Hover over the panel on the left which lists "Brush", "Brush Tip", "Blending Mode", "Opacity" etc. 6. While hovering, scroll the scroll wheel. (For the pixel brush at least, the list is too long to fit in the space, so we want to scroll to see all the options) Actual Results: 1. Noticeable lag. 2. The selected brush engine sort of switches from pixel brush to the other brush you selected before: The other brush engine is highlighted, but some tabs contain an unholy mess of widgets belonging to both brush engines (see attached image). Other results that sometimes happen: Brush settings flickers Brush settings becomes much smaller, then flicks back to being the right size Brush settings changes position (e.g. shifts about one toolbar icon to the right), then moves back. Expected Results: No Lag. Scroll Events affect only the widget under the cursor (the list of brush engine options, not the list of brush engines). The brush settings popup does *not* jump about like a drunken fool. Seems to persist after closing and reopening the Brush settings dialog. Some of the actual behaviour seems to depend on combinations of what is selected when the scroll event happens.
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