absolute positioning and other "missing features" of Wayland

[Jonas Ådahl]

On Mon, Feb 22, 2021 at 10:49:33AM +0000, Simon Ser wrote:
> On Monday, February 22nd, 2021 at 11:44 AM, Carsten Haitzler <raster at rasterman.com> wrote:
> 
> > I also would want to avoid baking explicit absolute positioning into wayland
> > protocol - be it as a core agreed to add-on to xdg-shell or even a "commonly
> > supported extension". What I'd like it some better solution. For example - if
> > an app wants to absolute position a window because it's doing a custom "my own
> > notification popup" much like Chrome and Firefox now like to do in X11, then I'd
> > prefer this be explicitly exposed as a "notification surface with requested
> > screen location hints" and so the compositor can decide to do something more
> > intelligent with it. I am sure this list of use cases will probably be
> > extensive and also depend on the API in wine that is being wrapped and
> > intercepted - the higher level it is, the more it knows about the intended use
> > case.
> 
> I'd like to avoid making this general, if we go down this road. Make it
> specific to the win32 API and wine. Wayland-native toolkits don't need
> it.

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.

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

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.

> 
> Notifications popups are part of the desktop environment and clients
> shouldn't try to display them directly.

Agreed.


Jonas