absolute positioning and other "missing features" of Wayland

Jonas Ådahl jadahl at gmail.com
Mon Feb 22 13:44:54 UTC 2021


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:
> 
> > 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.)

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




More information about the wayland-devel mailing list