Bug 304249 - Long delay when moving window through title bar
Summary: Long delay when moving window through title bar
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: aurorae (show other bugs)
Version: 4.8.97
Platform: unspecified Linux
: NOR normal
Target Milestone: 4.9.1
Assignee: Martin Flöser
URL:
Keywords: regression
: 304419 304542 304618 306179 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-07-29 16:32 UTC by Martin Flöser
Modified: 2012-11-23 22:02 UTC (History)
6 users (show)

See Also:
Latest Commit:
Version Fixed In: 4.9.1


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Flöser 2012-07-29 16:32:38 UTC
When trying to move a window through left click and move on titlebar in an Aurorae theme, the movement is too long compared to other decorations.

Steps to reproduce:
1. Select an Aurorae theme
2. Left click title bar and hold
3. move mouse

Expected behavior:
Window starts to move once the drag distance has passed

Actual behavior
The window starts to move only after the drag time has passed that is after quite a lot of moved pixels.
Comment 1 Martin Flöser 2012-08-02 06:12:41 UTC
*** Bug 304419 has been marked as a duplicate of this bug. ***
Comment 2 Martin Flöser 2012-08-02 08:51:05 UTC
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
Comment 3 Martin Flöser 2012-08-05 06:15:24 UTC
*** Bug 304542 has been marked as a duplicate of this bug. ***
Comment 4 Christoph Feck 2012-08-05 14:31:59 UTC
*** Bug 304618 has been marked as a duplicate of this bug. ***
Comment 5 Christoph Feck 2012-09-03 01:11:08 UTC
*** Bug 306179 has been marked as a duplicate of this bug. ***
Comment 6 Eisenberger Tamás 2012-11-22 21:52:16 UTC
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?
Comment 7 Thomas Lübking 2012-11-22 22:12:16 UTC
Unlikely.
How's drag performance when you suspend the compositor? (shift+alt+f12)
Comment 8 Eisenberger Tamás 2012-11-22 22:25:11 UTC
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)
Comment 9 Thomas Lübking 2012-11-22 22:49:33 UTC
(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&"?
Comment 10 Eisenberger Tamás 2012-11-23 08:22:43 UTC
(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
Comment 11 Thomas Lübking 2012-11-23 22:02:10 UTC
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.