<div dir="ltr"><div dir="ltr"><div>Thanks everyone! This was quite a bit of interesting feedback.</div><div><br></div><div>Let me add Alexandros to this thread, too, in case he has any input - if the existing hacks seem to be sufficient, or if it makes sense to create a new protocol.</div><div><br></div><div>(Alexandros: I'm by no means an expert here, but saw your work on Wine, and thought it would be useful to start a discussion. If you're not already on the mailing list, see the full thread here: <a href="https://lists.freedesktop.org/archives/wayland-devel/2021-February/041718.html">https://lists.freedesktop.org/archives/wayland-devel/2021-February/041718.html</a> )<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Feb 22, 2021 at 9:23 AM Carsten Haitzler <<a href="mailto:raster@rasterman.com">raster@rasterman.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, 22 Feb 2021 12:10:08 +0100 Jonas Ådahl <<a href="mailto:jadahl@gmail.com" target="_blank">jadahl@gmail.com</a>> said:<br>
<br>
> On Mon, Feb 22, 2021 at 10:49:33AM +0000, Simon Ser wrote:<br>
> > On Monday, February 22nd, 2021 at 11:44 AM, Carsten Haitzler<br>
> > <<a href="mailto:raster@rasterman.com" target="_blank">raster@rasterman.com</a>> wrote:<br>
> > <br>
> > > I also would want to avoid baking explicit absolute positioning into<br>
> > > wayland protocol - be it as a core agreed to add-on to xdg-shell or even<br>
> > > a "commonly supported extension". What I'd like it some better solution.<br>
> > > For example - if an app wants to absolute position a window because it's<br>
> > > doing a custom "my own notification popup" much like Chrome and Firefox<br>
> > > now like to do in X11, then I'd prefer this be explicitly exposed as a<br>
> > > "notification surface with requested screen location hints" and so the<br>
> > > compositor can decide to do something more intelligent with it. I am sure<br>
> > > this list of use cases will probably be extensive and also depend on the<br>
> > > API in wine that is being wrapped and intercepted - the higher level it<br>
> > > is, the more it knows about the intended use case.<br>
> > <br>
> > I'd like to avoid making this general, if we go down this road. Make it<br>
> > specific to the win32 API and wine. Wayland-native toolkits don't need<br>
> > it.<br>
> <br>
> Sounds potentially not horrible in theory, but is it remotely possible?<br>
> There are these approaches I can think of:<br>
<br>
It's still open to abuse eventually for the wrong reasons no matter where it<br>
is.<br>
<br>
>  * Add a "wl_win32" to wayland-protocols<br>
> <br>
> Adoption by anyone wanting to bypass the Wayland windowing model can use<br>
> it trivially, and we have a X11 like situation where everything grabs<br>
> everything and arbitrary client driven window self management.<br>
> <br>
>  * Make "wine" distribute a "wl_win32.xml" and make compositors depend on<br>
>    on wine-devel, implementing the protocol.<br>
> <br>
> Practically the same as above, just a 'cp ~/wine/protocols/wl-win32<br>
> protocols' away, and we're back with wierd grabs and client managing<br>
> their own surfaces again.<br>
> <br>
>  * A libwine-wayland, a wineBindWaylandDisplay() with some kind of half<br>
>    assed authentication.<br>
> <br>
> I assume noone wants this (including me). But client developers would<br>
> have to be really obnoxious to work around it which might be enough to<br>
> not make it general.<br>
> <br>
> A "allow/deny" nag/query (aka "Do you want this application you<br>
> installed to work or want me to break it for you?") I wouldn't call a<br>
> reasonable option either.<br>
<br>
I think the nag is probably the way to go. Or specifically the compositor<br>
should ask once and remember the response (or have an option to never ask and<br>
always allow this if users so desire). <br>
<br>
> So, how would we make it not de-facto general?<br>
> <br>
> Not to meantion the head ache of letting clients in on configuring their<br>
> window positions when any kind of HiDPI scaling, fractional or nat, is<br>
> done.<br>
<br>
Indeed this is the problem as well as odd displays like circular ones as well.<br>
It opens the doors to clients making assumptions that may not be true given<br>
various methods a compositor might use to handle multiple screens with<br>
differing DPI/scaling etc.<br>
<br>
> > <br>
> > Notifications popups are part of the desktop environment and clients<br>
> > shouldn't try to display them directly.<br>
<br>
But they do. Give them an inch and they take a mile. :)<br>
<br>
> Agreed.<br>
> <br>
> <br>
> Jonas<br>
> <br>
<br>
<br>
-- <br>
------------- Codito, ergo sum - "I code, therefore I am" --------------<br>
Carsten Haitzler - <a href="mailto:raster@rasterman.com" target="_blank">raster@rasterman.com</a><br>
<br>
</blockquote></div></div>