Summary: | TabBox no longer allows mouse wheel | ||
---|---|---|---|
Product: | [Plasma] kwin | Reporter: | Luke-Jr <luke-jr+kdebugs> |
Component: | tabbox | Assignee: | KWin default assignee <kwin-bugs-null> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | kde, kwin-bugs-null, thomas.pfeiffer |
Priority: | NOR | Flags: | kde:
Usability?
mgraesslin: ReviewRequest+ |
Version: | 5.8.0 | ||
Target Milestone: | --- | ||
Platform: | Other | ||
OS: | Linux | ||
URL: | https://phabricator.kde.org/D2953 | ||
Latest Commit: | http://commits.kde.org/kwin/e9d20b80e9a79f514a219357d991092d83665350 | Version Fixed In: | 5.8.2 |
Description
Luke-Jr
2016-10-03 04:42:13 UTC
It's less a bug than a wishlist item (even if it existed in previous versions), but it doesn't exactly conflict with anything else so I don't see a reason why not to bring it back. Re-assigning to Kwin as wheeling outside the dialog actually works, so there's some event handling issue there. Investigation shows that we don't get any xcb button press/release events when on the tabbox but we get them as soon as as the mouse is outside the tabbox. Furthermore we get xcb_ge_generic events on the tabbox which might indicate that it's xinput2 events. So ideas: either intercept xinput2 events or intercept the QWheelEvent on the QWindow. In general we grabbed the xcb events to ensure the grabbed events get passed to effects and handle the outside of window area correctly. But that works, so we don't necessarily need to filter the xinput events. So the easier change for 5.8 might be to just intercept the QWheelEvents. For 5.9 it might be an idea to rethink the complete xcb event interaction and finally move it to a filter instead of the checks inside events.cpp Addressed with https://phabricator.kde.org/D2953 Thanks, I tested and reviewed the code changes. Git commit e9d20b80e9a79f514a219357d991092d83665350 by Martin Gräßlin. Committed on 17/10/2016 at 06:23. Pushed by graesslin into branch 'Plasma/5.8'. [tabbox] Intercept QWheelEvents on QQuickWindow for scrolling Summary: The TabBox performs the scrolling of the items by itself in order to support wheel events even if the mouse is not on the TabBox. For that KWin grabs pointer events on X11 (on Wayland an input filter is used) and forwards them to the TabBox. Qt uses Xinput2 for scrolling on the QQuickWindow. Due to that KWin does not get any xcb core button press/release events when scrolling inside the QQuickWindow and thus scrolling doesn't work. There are three possible approaches to fix this: 1. Implement scrolling support in each of the QML switchers 2. Add an xinput2 filter to TabBox 3. Intercept the QWheelEvents on the QQuickWindow The first approach has the disadvantage that all themes need adjustment and that there might be behaviorial difference whether one scrolls on the TabBox window or outside the window. The second approach would be most in line with the other filters, but is difficult due to the nature of xinput2 (no xcb bindings, etc). Thus the third approach might be the best solution. Wheel events are only delivered to the QQuickWindow if the native events were not already intercepted, thus we know it won't have side effects for the case that Wayland is used or xinput2 is not supported. The implementation installs an event filter on the QQuickWindow which gets created when showing the TabBox and inside the filter waits till there is an angleDelta of +/-120 and scrolls by one per every 120 angle delta as described in the QWheelEvent documentation. FIXED-IN: 5.8.2 Test Plan: Scrolled with touchpad and mouse wheel. Reviewers: #kwin, #plasma, broulik Subscribers: plasma-devel, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D2953 M +32 -0 tabbox/tabboxhandler.cpp M +2 -0 tabbox/tabboxhandler.h http://commits.kde.org/kwin/e9d20b80e9a79f514a219357d991092d83665350 |