On Mon, 22 Feb 2021 14:44:54 +0100 Jonas Ådahl <jad...@gmail.com> 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 <jad...@gmail.com> 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