absolute positioning and other "missing features" of Wayland

[Carsten Haitzler]

On Mon, 22 Feb 2021 12:10:08 +0100 Jonas Ådahl <jadahl at gmail.com> said:

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

It's still open to abuse eventually for the wrong reasons no matter where it
is.

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

I think the nag is probably the way to go. Or specifically the compositor
should ask once and remember the response (or have an option to never ask and
always allow this if users so desire). 

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

Indeed this is the problem as well as odd displays like circular ones as well.
It opens the doors to clients making assumptions that may not be true given
various methods a compositor might use to handle multiple screens with
differing DPI/scaling etc.

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

But they do. Give them an inch and they take a mile. :)

> Agreed.
> 
> 
> Jonas
> 


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
Carsten Haitzler - raster at rasterman.com