Summary: | Window contents also scroll while using alt + scroll wheel to change opacity | ||
---|---|---|---|
Product: | [Plasma] kwin | Reporter: | Kishore Gopalakrishnan <kishore96> |
Component: | general | Assignee: | KWin default assignee <kwin-bugs-null> |
Status: | RESOLVED INTENTIONAL | ||
Severity: | normal | ||
Priority: | NOR | ||
Version: | 5.12.4 | ||
Target Milestone: | --- | ||
Platform: | Arch Linux | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
Kishore Gopalakrishnan
2018-04-06 13:00:34 UTC
Is this on X11 or Wayland? (In reply to Martin Flöser from comment #1) > Is this on X11 or Wayland? This is on X11. I haven't tested on Wayland. The reason for this problem is that KWin does not support xinput scrolling, but the application use xinput. KWin only grabs the mouse button, but not xinput. As KWin is feature frozen for X11 we cannot add support for xinput scrolling. To a certain degree this is also an application bug as they accept mouse events although another application has a mouse grab. (In reply to Martin Flöser from comment #3) > To a certain degree this is also an application bug as they > accept mouse events although another application has a mouse grab. This seems to happen in all QT5 applications. However it doesn't seem to happen in GTK applications (I tested with GIMP). Should I report a QT bug? Please test a gtk-3 application instead of Gimp. If you cannot reproduce there it should be reported to Qt. (In reply to Martin Flöser from comment #5) > Please test a gtk-3 application instead of Gimp. If you cannot reproduce > there it should be reported to Qt. I cannot reproduce this with gedit. Is it alright if I just report the bug to Qt as 'Qt applications accept mouse events although another application has a mouse grab', or is there some other relevant information I would need to give them for this bug? Best describe the complete situation and also that gtk-3 doesn't have this problem |