Summary: | Long delay when moving window through title bar | ||
---|---|---|---|
Product: | [Plasma] kwin | Reporter: | Martin Flöser <mgraesslin> |
Component: | aurorae | Assignee: | Martin Flöser <mgraesslin> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | dgdanielf, god, illumilore, kwin-bugs-null, lnxusr, tamas |
Priority: | NOR | Keywords: | regression |
Version: | 4.8.97 | ||
Target Milestone: | 4.9.1 | ||
Platform: | unspecified | ||
OS: | Linux | ||
Latest Commit: | http://commits.kde.org/kde-workspace/9ee6a775d592ec3f105892c32c7576d6cdd7c210 | Version Fixed In: | 4.9.1 |
Description
Martin Flöser
2012-07-29 16:32:38 UTC
*** Bug 304419 has been marked as a duplicate of this bug. *** Git commit 9ee6a775d592ec3f105892c32c7576d6cdd7c210 by Martin Gräßlin. Committed on 29/07/2012 at 22:03. Pushed by graesslin into branch 'KDE/4.9'. Do not accept left mouse press events on titlebar in Aurorae Accepting the mouse events breaks moving the window by dragging the title bar. The reason is that it eats the mouse event and by that never reaches KWin core to perform the movement. Other mouse buttons need to be accepted for handling the window operations. Also we need to listen in general to left mouse button for the double click operation. FIXED-IN: 4.9.1 REVIEW: 105784 M +7 -1 kwin/clients/aurorae/src/qml/aurorae.qml http://commits.kde.org/kde-workspace/9ee6a775d592ec3f105892c32c7576d6cdd7c210 *** Bug 304542 has been marked as a duplicate of this bug. *** *** Bug 304618 has been marked as a duplicate of this bug. *** *** Bug 306179 has been marked as a duplicate of this bug. *** Hey, I've the very same effect not only on window decorations but for every drag using kde 4.9.3.. Is this the same problem or what? Unlikely. How's drag performance when you suspend the compositor? (shift+alt+f12) It's the same when I disable the compositor.. I've also tried to set drag start delay and drag start distance, these are also does nothing. It only happens with my external mouse, drag works fine with my touchpad. It's the same in every app (qt / gtk) and the decoration Should I report a new bug? Thanks for the help! (In reply to comment #7) > Unlikely. > How's drag performance when you suspend the compositor? (shift+alt+f12) (In reply to comment #8) > It only happens with my external mouse, drag works fine with my touchpad. That would be most relevant and point the X11 input driver. Alt+LeftMouseButton dragging is equally slow, i assume? Tried replacing the WM, eg. (if installed) "openbox --replace&"? (In reply to comment #9) Yes, alt dragging is also slow.. When I switch to metacity its also slow.. But, when I start a gnome or gnome failsafe session it works correctly Ok, this is a completely unrelated issue. Please gather some information (esp. cpu load) when dragging, ideally make a video and head over to forum.kde.org (Workspace/KWin is ok for now) so we can first determine what actually is the issue, then what's causing it (apparently not kwin) and then deal with it w/o further spamming this bug. |