[Bug 38753]

[Mgraesslin]

> I'm not sure if that'd suffice. Consider the situation:

We considered this situation during our discussions and came to the
conclusion that it's out of scope. The drag is performed from the active
window, for the compositor it's impossible to know that the user clicked
the window to perform a drag and that's also not how the Wayland
protocol allows to start a drag (the click must(!) be passed to the
window).

There are multiple ways now to circumvent the problem:
* mark the "destination" window as keep above
* use Alt+Tab during drag and drop to change window
* use Present Windows (that needs implementation) to change window
* use task bar to switch windows

We also think that the users are able to realize that they cannot drag
from a maximized window and will change the geometry before. Just like
users use split screen in Dolphin to better support drag'n'drop.

-- 
You received this bug notification because you are a member of Kubuntu
Bugs, which is subscribed to kdebase-workspace in Ubuntu.
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