absolute positioning and other "missing features" of Wayland

Simon Ser contact at emersion.fr
Mon Feb 22 11:21:04 UTC 2021


On Monday, February 22nd, 2021 at 12:10 PM, Jonas Ådahl <jadahl at gmail.com> wrote:

> Sounds potentially not horrible in theory, but is it remotely possible?
> There are these approaches I can think of:
>
>  * Add a "wl_win32" to wayland-protocols
>
> Adoption by anyone wanting to bypass the Wayland windowing model can use
> it trivially, and we have a X11 like situation where everything grabs
> everything and arbitrary client driven window self management.
>
>  * Make "wine" distribute a "wl_win32.xml" and make compositors depend on
>    on wine-devel, implementing the protocol.
>
> Practically the same as above, just a 'cp ~/wine/protocols/wl-win32
> protocols' away, and we're back with wierd grabs and client managing
> their own surfaces again.

I like to have wayland-protocols as a space shared between client and
compositor developers. Having the protocol in a client code-base
doesn't make it clear that the compositor folks need to ack new
versions.

>  * A libwine-wayland, a wineBindWaylandDisplay() with some kind of half
>    assed authentication.
>
> I assume noone wants this (including me). But client developers would
> have to be really obnoxious to work around it which might be enough to
> not make it general.

Hm, right, I'd really like to avoid this. The authentication would be
useless anyways.

> A "allow/deny" nag/query (aka "Do you want this application you
> installed to work or want me to break it for you?") I wouldn't call a
> reasonable option either.
>
> So, how would we make it not de-facto general?
>
> Not to meantion the head ache of letting clients in on configuring their
> window positions when any kind of HiDPI scaling, fractional or nat, is
> done.

Maybe use e.g. security-context [1] or similar to be able to hide
wine-specific Wayland interfaces from applications that don't need it.
Would need some kind of metadata in Flatpak and friends to allow win32
apps to opt-in.

But before anything happens, try to make win32 work as much as possible
with just xdg-shell. Alexandros Frantzis seems to have made good
progress [2] on that front already.

[1]: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/68
[2]: https://www.collabora.com/news-and-blog/news-and-events/wayland-on-wine-an-exciting-first-update.html


More information about the wayland-devel mailing list