On Fri Jul 5 20:18:21 2024 +0000, Alexandros Frantzis wrote:
Hi Anna, thanks for the MR. I have also recently been working on a branch that tackles the same issue (among other things). I pushed my current WIP so you can take a look: https://gitlab.winehq.org/afrantzis/wine/-/commits/wip/use-subsurfaces A major difference between the two approaches is that my WIP is using wl_subsurface instead of xdg_popup. The reason is that the behavior of transient (and other "unmanaged") windows in win32 is supposed to be under the control of the application. wl_subsurface is a good match here because it doesn't introduce any additional compositor behavior, whereas xdg_popup gives a lot more control to the compositor (I have concerns especially about compositor side dismissals). Some other notes:
- Win32 owned windows are a more general concept than xdg_popups.
Although many owned windows are indeed transient windows, some are not (e.g., dialogs) and are better served by another mechanism (e.g., xdg_toplevel parent/child), or no mechanism at all (see my thoughts above about not introducing any additional behavior on top of win32).
- Inversely, some transient windows are not owned, and we need to guess
a suitable parent if we want to anchor them to another wayland surface (see, e.g., my WIP branch). In terms of next steps, my proposal is that I first finish and land the subsurfaces functionality, since it provides the least friction in terms of win32/wayland behavior, and is needed for other things anyway. Then I think we will have a clearer view, as a well as a base to compare against, in order to explore how and when to utilize xdg_popups to achieve better integration. How does that sound?
hello, thanks for the feedback
i, well, had no wine or win32 experience before writing this, and spent half a day yesterday trying to understand both, and since wayland i know, started there. so, apologies i didn't know much of win32.
Win32 owned windows are a more general concept than xdg_popups
considering this, i do agree subsurfaces make more sense in the general case.
Inversely, some transient windows are not owned, and we need to guess a suitable parent if we want to anchor them to another wayland surface (see, e.g., my WIP branch).
i noticed this on winecfg, where the dropdowns were like that and didn't properly get matched, tried to poke at that today but didn't have much time to find out a way.
some are not (e.g., dialogs) and are better served by another mechanism (e.g., xdg_toplevel parent/child),
was using xdg_dialog thought of for win32 dialogs?
Then I think we will have a clearer view, as a well as a base to compare against, in order to explore how and when to utilize xdg_popups to achieve better integration. How does that sound?
that sounds good.
--
ps: i've also been working on patches to use xdg_decoration to conditionally use server side decorations like the x11drv does, if that's of any interest