absolute positioning and other "missing features" of Wayland

[Pekka Paalanen]

On Mon, 22 Feb 2021 14:44:54 +0100
Jonas Ådahl <jadahl at 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 <jadahl at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20210222/e00314af/attachment.sig>