Problem scenario: 1. Maximized window in the background (unfocused) (e.g. dolphin) 2. Windowed window in the foreground (focused) (e.g. thunderbird new email window) If I want to drag a file from dolphin to thunderbird in order to attach it to the email this is not possible, because once I long click on the file on dolphin, the dolphin window is brought to the foreground hiding the thunderbird window. To achieve the result, I need to either set thunderbird to "always on top" or de-maximize dolphin and put the two windows side by side. If instead of raising on the mouse button down click, the dolphin window will be raised on mouse button release, it would be possible to drag and drop as described above. In other words, when drag and dropping the dolphin window will not be raised, while it will be raised on a single click. A similar behaviour can be obtained by changing the following setting: System Settings > Window Management > Window Actions > Left Button to "Activates & Pass Click" but this then causes the annoying behaviour of requiring two clicks to raise the window at any time, which is not desiderable.
This works fine on Wayland. On Wayland the window a window gets raised when hovering over it during the drag and drop operation. On X11 this is not possible. Many applications react on the press by trying to raise themselves, so it would result in a very inconsistent and broken behavior.
The problem I was trying to describe is not that the target window is not raised during the drag and drop operation, but that the source window is raised as soon as we click on it. The source window should not be raised at any stage of the drag and drop operation. This behaviour is present also in Wayland. (The problem you describe is indeed present in X11 and solved in Wayland).
Probably what I'm describing is the same as the problem described in this blog post: https://blogs.gnome.org/metacity/2008/06/11/drag-and-drop/ I don't really understand why the author states: "Always raising the lower window only on release, not on click (suggested by many people). This would solve the problem at the cost of weirding everyone out" To me raising on mouse button release should not create any weird behaviour. Indeed if the click doesn't start a drag, why would one keep the mouse button down? Selecting text maybe? The mouse release would instantly follow the mouse click.
We won't change the behavior when to react on button press. I'm sorry. On Wayland we circumvent the problem and that is sufficient. What matters is whether drag and drop works in a reliable way and that the user can drag to any position. This is possible. Whether the window gets raised on button press or not is in the end irrelevant as long as the workflow is possible.
Created attachment 105378 [details] Bug under X11
"What matters is whether drag and drop works in a reliable way and that the user can drag to any position. This is possible." This is impossible. See video attached. The video is taken under X11, but the behaviour is the same under Wayland. I can upload a video taken in Wayland if necessary. I don't care about raising or not the windows, I just would like to be able to drag and drop from any position without having to tinker with the windows.
> This is impossible. I just gave it a try. You can without problems drag over the taskbar item and it raises the window. Or you can use alt+tab during the drag.
Ok, possible, by performing extra actions, which is not what we were talking about. Moreover it is less intuitive than the behaviour I suggest. I knew I could do it by dragging over the taskbar, but I found it extremely cumbersome. I never thought about Alt+Tab. Just to let you know I'm not the only one that find this not so intuitive. https://forum.kde.org/viewtopic.php?f=91&t=76167 https://forum.kde.org/viewtopic.php?sid=a8e8441f213344cc97ed50f7e843ccaa&t=62491 Moreover I don't understand why not implementing it (at least in Wayland if it allows it) IF it won't break any workflows but just extend the current one. ( I don't want it implemented tomorrow, but your answer is never). In any case I won't insist anymore and thanks for your work.