absolute positioning and other "missing features" of Wayland

[Jonas Ådahl]

On Mon, Feb 22, 2021 at 11:21:04AM +0000, Simon Ser wrote:
> 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.

This idea would be a bit like the `xwayland_output` replacing parts of
`xdg_output` that has been discussed, where xwayland itself is the owner
and distributor of this protocol file. Just because it'd be the only
potential user. I agree it's not a good fit here.

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

Would would be quite similar to a "Would you like me to stop breaking
your application?" approach, except moved to packagers and angry users
not using Flatpak like setups that has to find the "Unbreak my system"
setting.

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

Right, and it's nice to see steps are taken to try to translate what was
previously done the X11 way e.g using viewports instead of changing the
monitor resolution, and parent relative surface positioning for menus
etc, but one will have to accept it's not likely possible to be
completely feature complete using the "Wayland windowing model" as a
backbone, as some of those features are considered anti-fatures in that
model.


Jonas