Difficulties with Wayland D&D protocol - D&D source persistence

2022-10-24 Thread Martin Stransky

Hi folks,

I'd like to point out how Wayland D&D protocol limits real life 
applications.


Main limitation is a requirement that D&D source window has to be kept 
opened and D&D is cancelled otherwise.


That's especially painful with popups. See this Mozilla bug and video 
attached there [1].


What's the problem?

- When a popup window is source of D&D (a bookmark entry on the example 
here), we can't close it.


- It's difficult to do D&D to another popup as the source one has to me 
kept opened. That means we need to show popups which are not intended to 
be shown together:

 - if the popups are adjacent, xdg-positoner can be used.
 - if the popups are not adjacent (an example on the clip), 
wl_subsurface popup has to be used with its consequences (buggy 
compositor/gtk3 implementation).


So may be the D&D source persistence condition relaxed?

Thanks,
Martin

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1797046

--
Martin Stransky
Software Engineer / Red Hat, Inc



Re: Difficulties with Wayland D&D protocol - D&D source persistence

2022-10-24 Thread Carlos Garnacho
Hi Martin,


On Mon, Oct 24, 2022 at 11:43 AM Martin Stransky  wrote:
>
> Hi folks,
>
> I'd like to point out how Wayland D&D protocol limits real life
> applications.
>
> Main limitation is a requirement that D&D source window has to be kept
> opened and D&D is cancelled otherwise.
>
> That's especially painful with popups. See this Mozilla bug and video
> attached there [1].

OTOH it is also what makes DnD neatly abort if the source surface and
its ongoing operations got legitimately destroyed.

>
> What's the problem?
>
> - When a popup window is source of D&D (a bookmark entry on the example
> here), we can't close it.
>
> - It's difficult to do D&D to another popup as the source one has to me
> kept opened. That means we need to show popups which are not intended to
> be shown together:
>   - if the popups are adjacent, xdg-positoner can be used.
>   - if the popups are not adjacent (an example on the clip),
> wl_subsurface popup has to be used with its consequences (buggy
> compositor/gtk3 implementation).
>
> So may be the D&D source persistence condition relaxed?

To allow a fix for this case, I think it would be more backwards
compatible and coherent to relax wl_data_device.start_drag conditions,
so that it's only required that the serial/grab is on a surface of the
same client, and a different source surface may be used. Firefox could
then pass the toplevel surface as the drag source. This way lifetime
correctness is guaranteed, and "snap back" animations on failed DnD
have a surface to return to.

Cheers,
  Carlos