Re: absolute positioning and other "missing features" of Wayland
Thanks everyone! This was quite a bit of interesting feedback. 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. (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: https://lists.freedesktop.org/archives/wayland-devel/2021-February/041718.html ) On Mon, Feb 22, 2021 at 9:23 AM Carsten Haitzler wrote: > On Mon, 22 Feb 2021 12:10:08 +0100 Jonas Ådahl said: > > > On Mon, Feb 22, 2021 at 10:49:33AM +, Simon Ser wrote: > > > On Monday, February 22nd, 2021 at 11:44 AM, Carsten Haitzler > > > 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 - ras...@rasterman.com > > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: absolute positioning and other "missing features" of Wayland
On Mon, 22 Feb 2021 12:10:08 +0100 Jonas Ådahl said: > On Mon, Feb 22, 2021 at 10:49:33AM +, Simon Ser wrote: > > On Monday, February 22nd, 2021 at 11:44 AM, Carsten Haitzler > > 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 - ras...@rasterman.com ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: absolute positioning and other "missing features" of Wayland
On Mon, 22 Feb 2021 14:44:54 +0100 Jonas Ådahl wrote: > On Mon, Feb 22, 2021 at 01:56:46PM +0200, Pekka Paalanen wrote: > > On Mon, 22 Feb 2021 12:10:08 +0100 > > Jonas Ådahl wrote: > > > > > 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. > > > > I haven't yet seen anyone say that if a coordinate system is exposed, > > it must cover the outputs exactly and it must be at output pixel scale > > or whatever. It only needs to be just enough from a client perspective > > and for an existing application. > > > > Maybe it is enough to create a new coordinate system object, and make > > it the size of the "desktop application area" rather than output size > > or desktop size. That is, the area normally taken by a maximized app, > > for instance. Then, one could register xdg_toplevels with that > > coordinate system object so they can see and set their position with > > respect to that coordinate system. A bit like rootful Xwayland or the > > Wine virtual desktop, except without the actual root window. Maybe or > > maybe not allow other windows in between in the z-order. Always-on-top > > semantics would be restricted within the coordinate system object. And > > so on? > > > > A coordinate system itself could perhaps be tied to one specific > > xdg_toplevel, using the surface coordinate system of it as the basis. > > > > Obviously you can't make a real fullscreen window, or maybe not even a > > real maximized window, with just position and size in this design, or > > obscure all other windows. Maybe it's also restricted to a single > > Wayland output at a time, too. The compositor would be free to decide > > the size and positioning of this 2D coordinate space. > > > > But that's is quite far in the general direction hand waving, because I > > don't know what Wine specifically would need. > > TBH, this just sounds like a dumbed down X11 like window management with > a few limitations. That is exactly what it aims to be, for the case where literally nothing else works. Whether such cases are worthwhile, is a whole another matter. > But it's too speculative for me to make any actual > sense of, I don't know what kind of wine problems you intend to solve > with all of that. > > I'd rather we look at each particular case that comes up in detail that > comes up, that require some X11 style control, and look at how it can be > emulated, instead of speculating about how much X11 semantics needs to > be ported over to make wine feature complete enough. Yes! Definitely, I'm totally 100% of the same opinion. This whole discussion started with the assumption that reasonable solutions are not enough, so I ran with that. Thanks, pq pgpeA2Cq9o2kJ.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: absolute positioning and other "missing features" of Wayland
On Mon, Feb 22, 2021 at 01:56:46PM +0200, Pekka Paalanen wrote: > On Mon, 22 Feb 2021 12:10:08 +0100 > Jonas Ådahl wrote: > > > On Mon, Feb 22, 2021 at 10:49:33AM +, Simon Ser wrote: > > > > 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. > > While this is definitely a concern, I wouldn't be that pessimistic. The > interface can be named e.g. ext_win32_foreign_window_system to make it > feel awkward to be used in normal apps. (Not wp_ namespace, either.) I don't think any prefixing makes any difference if it's widely available enough (or anywhere, and just broken experience where it's not), for anyone that just wants to get the job done. > > Also, if tailored specifically for Wine and Win32 to fill in gaps, maybe > it is not generally that useful. It might be easier for normal apps to > just play by the book than try to twist that to do their bidding. I don't believe that will help. If it quacks like a duck, it's a duck, even if it has a win95 theme. And I naively assume that the things that some apps want to do that is not possible on Wayland, is quite similar to these missing wine features. Then again, I'm also just speculating. > > I'd still put it in wayland-protocols. > > > So, how would we make it not de-facto general? > > I would hope that happens by tailoring it specifically for Wine, using > Win32 and Wine terminology. > > > 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. > > I haven't yet seen anyone say that if a coordinate system is exposed, > it must cover the outputs exactly and it must be at output pixel scale > or whatever. It only needs to be just enough from a client perspective > and for an existing application. > > Maybe it is enough to create a new coordinate system object, and make > it the size of the "desktop application area" rather than output size > or desktop size. That is, the area normally taken by a maximized app, > for instance. Then, one could register xdg_toplevels with that > coordinate system object so they can see and set their position with > respect to that coordinate system. A bit like rootful Xwayland or the > Wine virtual desktop, except without the actual root window. Maybe or > maybe not allow other windows in between in the z-order. Always-on-top > semantics would be restricted within the coordinate system object. And > so on? > > A coordinate system itself could perhaps be tied to one specific > xdg_toplevel, using the surface coordinate system of it as the basis. > > Obviously you can't make a real fullscreen window, or maybe not even a > real maximized window, with just position and size in this design, or > obscure all other windows. Maybe it's also restricted to a single > Wayland output at a time, too. The compositor would be free to decide > the size and positioning of this 2D coordinate space. > > But that's is quite far in the general direction hand waving, because I > don't know what Wine specifically would need. TBH, this just sounds like a dumbed down X11 like window management with a few limitations. But it's too speculative for me to make any actual sense of, I don't know what kind of wine problems you intend to solve with all of that. I'd rather we look at each particular case that comes up in detail that comes up, that require some X11 style control, and look at how it can be emulated, instead of speculating about how much X11 semantics needs to be ported over to make wine feature complete enough. Jonas > > > Thanks, > pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: absolute positioning and other "missing features" of Wayland
On Mon, 22 Feb 2021 12:10:08 +0100 Jonas Ådahl wrote: > On Mon, Feb 22, 2021 at 10:49:33AM +, Simon Ser wrote: > > 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. While this is definitely a concern, I wouldn't be that pessimistic. The interface can be named e.g. ext_win32_foreign_window_system to make it feel awkward to be used in normal apps. (Not wp_ namespace, either.) Also, if tailored specifically for Wine and Win32 to fill in gaps, maybe it is not generally that useful. It might be easier for normal apps to just play by the book than try to twist that to do their bidding. I'd still put it in wayland-protocols. > So, how would we make it not de-facto general? I would hope that happens by tailoring it specifically for Wine, using Win32 and Wine terminology. > 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. I haven't yet seen anyone say that if a coordinate system is exposed, it must cover the outputs exactly and it must be at output pixel scale or whatever. It only needs to be just enough from a client perspective and for an existing application. Maybe it is enough to create a new coordinate system object, and make it the size of the "desktop application area" rather than output size or desktop size. That is, the area normally taken by a maximized app, for instance. Then, one could register xdg_toplevels with that coordinate system object so they can see and set their position with respect to that coordinate system. A bit like rootful Xwayland or the Wine virtual desktop, except without the actual root window. Maybe or maybe not allow other windows in between in the z-order. Always-on-top semantics would be restricted within the coordinate system object. And so on? A coordinate system itself could perhaps be tied to one specific xdg_toplevel, using the surface coordinate system of it as the basis. Obviously you can't make a real fullscreen window, or maybe not even a real maximized window, with just position and size in this design, or obscure all other windows. Maybe it's also restricted to a single Wayland output at a time, too. The compositor would be free to decide the size and positioning of this 2D coordinate space. But that's is quite far in the general direction hand waving, because I don't know what Wine specifically would need. Thanks, pq pgpYQcrieI25x.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: absolute positioning and other "missing features" of Wayland
On Mon, Feb 22, 2021 at 11:21:04AM +, Simon Ser wrote: > On Monday, February 22nd, 2021 at 12:10 PM, Jonas Ådahl > 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 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: absolute positioning and other "missing features" of Wayland
On Monday, February 22nd, 2021 at 12:10 PM, Jonas Ådahl 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 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: absolute positioning and other "missing features" of Wayland
On Mon, Feb 22, 2021 at 10:49:33AM +, Simon Ser wrote: > On Monday, February 22nd, 2021 at 11:44 AM, Carsten Haitzler > 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 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: absolute positioning and other "missing features" of Wayland
On Monday, February 22nd, 2021 at 11:44 AM, Carsten Haitzler 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. Notifications popups are part of the desktop environment and clients shouldn't try to display them directly. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: absolute positioning and other "missing features" of Wayland
On Mon, 22 Feb 2021 12:14:56 +0200 Pekka Paalanen said: > On Fri, 19 Feb 2021 11:46:56 -0800 > Dima Ryazanov wrote: > > > Most Wayland compositors support XWayland, and therefore, are ok with > > applications using absolute positioning > > Hi, > > I don't think that is exactly true. With rootless Xwayland (the usual > case), the Wayland compositor also takes the explicit role of the X11 > window manager through X11 protocol. This is even how X11 is intended > to work and not some backdoor. Therefore, the Wayland compositor is > still in full control of all window management, including positioning, > even if X11 exposes a global coordinate system to X11 applications that > the Wayland compositor needs to fake. Kind of true... but override-redirect windows will bypass that positioning control the WM has... it's common to abuse these for all sorts of fun and games. > If Wine could really benefit from some optional hand-holding, I think > it would be okay to have a Windows-specific interface to help fill the > gaps. It wouldn't be that different from what Wayland compositors need > to do today to support Xwayland; a foreign window system integration. 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. > Even better if that's not necessary. > > > Thanks, > pq -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: absolute positioning and other "missing features" of Wayland
On Fri, 19 Feb 2021 11:46:56 -0800 Dima Ryazanov wrote: > Most Wayland compositors support XWayland, and therefore, are ok with > applications using absolute positioning Hi, I don't think that is exactly true. With rootless Xwayland (the usual case), the Wayland compositor also takes the explicit role of the X11 window manager through X11 protocol. This is even how X11 is intended to work and not some backdoor. Therefore, the Wayland compositor is still in full control of all window management, including positioning, even if X11 exposes a global coordinate system to X11 applications that the Wayland compositor needs to fake. If Wine could really benefit from some optional hand-holding, I think it would be okay to have a Windows-specific interface to help fill the gaps. It wouldn't be that different from what Wayland compositors need to do today to support Xwayland; a foreign window system integration. Even better if that's not necessary. Thanks, pq pgpll4mIO4QMS.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: absolute positioning and other "missing features" of Wayland
Hi Dima, Thank you for your correspondence on this. According to the previous announcement [0] good progress was made towards using a heuristic on popup windows to position them as subsurfaces, that seems like what Wine users would probably want to use in most cases because it preserves client isolation. Is anyone keeping track of a list of applications where this doesn't work? A set of test cases would be best here. It looks like additional compositor support would be needed only for applications where a heuristic absolutely doesn't work at all. I wouldn't say it's "evil" or "undesirable" to have something else a compositor can do there, but it probably would be wanted only as a last resort for the odd application that cannot be made to work securely. Thanks, - Jason [0]: https://www.winehq.org/pipermail/wine-devel/2020-December/178575.html ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
absolute positioning and other "missing features" of Wayland
Hi everyone, I realize this has always been a controversial topic; I apologize for bringing it up yet again, but I'm wondering if there could be some compromise here. I've been following the development of the Wayland driver for Wine [1] - and it's one of the examples where "applications shouldn't know or care about window positioning" doesn't really make sense. Wine is a compatibility layer; it's not up to Wine what the application is trying to do. Right now, properly supporting Wine on Wayland is (almost) impossible - and Wine developers' stance seems to be "We'll stay with X11 because Wayland is incomplete" [2]. Most Wayland compositors support XWayland, and therefore, are ok with applications using absolute positioning - as long as the application is using the X11 protocol. Would a Wayland protocol extension for this be a "lesser evil"? It could allow specific applications like Wine to access the "undesirable" features, while other applications would be restricted to the main protocols. Of course, nothing stops Gnome or any other compositor from implementing its own protocol for this - but I was hoping to hear some feedback and opinions, and possibly come up with a solution that everyone is happy with. [1] https://www.collabora.com/news-and-blog/news-and-events/wayland-on-wine-an-exciting-first-update.html [2] https://www.winehq.org/pipermail/wine-devel/2021-February/181338.html ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
