absolute positioning and other "missing features" of Wayland

[Pekka Paalanen]

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

> On Mon, Feb 22, 2021 at 10:49:33AM +0000, 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
-------------- 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/68ef0296/attachment.sig>