FYI, on windows, window management is completely done by the clients (so a client knows that this is gonna be a drag and can avoid the self-raise) The WM_TAKE_FOCUS protocol (despite the focus has really nothing to do with the stack order) pointed that direction (and sucks terribly because of broken client implementations... letting alone the focus stealing problems)
Raising on MB release would be possible (on caveats, see comment #37), but just cause other behavioral problems (if the user didn't want to drag something, but draw a selection frame etc.) About present windows to the rescue: *cough* https://git.reviewboard.kde.org/r/105341/ **COUGH** :-P Last thought: detect the drag (maybe even on X11 by listening to dnd messages rather than "something grabbed the pointer") and restore the stack if it happened within "the dnd timeout™" (which doesn't exist either - there's no guarantee Qt and Gtk wait the same amount of time), ie. lower the window we just raised (while even that could be nasty: assume the user wanted to dnd within the just raised client and suddenly it lowers again) tl;dr - clean up your f**** desktop ;-P -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/38753 Title: Inactive window "raise on click" should occur after click is released To manage notifications about this bug go to: https://bugs.launchpad.net/kde-baseapps/+bug/38753/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
