Comment 53 for bug 38753

(In reply to Martin Gräßlin from comment #45)
> > 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).

The problem is that this raise happens not on 'click' but on mouse-down itself.

>
> There are multiple ways now to circumvent the problem:
Exactly! These are ways to 'circumvent' the problem. The problem exists and it is disappointing to see that it'd still need to be worked around even though we now have a perfect opportunity to fix this - Wayland new Qt etc etc.

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

Hmm.. Users are not just 'able' to realise. They are forced to. And all these workaround statements can be equally applied to removing drag & drop altogether (for Dolphin, for example) saying that "users can just do Ctrl+C/X & Ctrl+V".

Anyway, if this is how we are 'fixing' this bug, please close it as WONTFIX rather than FIXED. Because that's what's happening to this bug report. No offense.