https://bugs.kde.org/show_bug.cgi?id=36065
--- Comment #45 from Martin Gräßlin <mgraess...@kde.org> --- > 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 are receiving this mail because: You are watching all bug changes.
