> 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 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
