Wayland and window position/size

Fri May 28 09:30:33 UTC 2021

Hi,

Carsten already replied well, so I'll just clarify a few little details
more.

On Thu, 27 May 2021 17:02:24 -0500
Igor Korot <ikorot01 at gmail.com> wrote:

> Hi, Pekka,
> 
> On Wed, May 26, 2021 at 4:30 AM Pekka Paalanen <ppaalanen at gmail.com> wrote:
> >
> > On Tue, 25 May 2021 22:10:38 -0500
> > Igor Korot <ikorot01 at gmail.com> wrote:
> >  
> > > Hi, Carsten,
> > >
> > > On Tue, May 25, 2021 at 8:51 PM Carsten Haitzler <raster at rasterman.com> wrote:  
> > > >
> > > > On Tue, 25 May 2021 16:24:30 -0500 Igor Korot <ikorot01 at gmail.com> said:
> > > >  
> > > > > Hi, list,
> > > > > Couple of questions about Wayland, since more and more distros switching ;-)

...

> > Wayland only defines that a window size cannot ever disagree with its
> > content size. That way there can never be undefined pixels on screen -
> > something that can happen with X11.  
> 
> And here we will have a problem.
> As said - the window initially does not have a content.
> Only a toolbar and a status bar.
> 
> And so when my application will start on Wayland I will get a very small window
> in size which will display only the toolbar.

I am talking in Wayland terms, which are very low-level terms.

You cannot make a window visible at all (the action is called "map") if
it does not have any content. Content includes everything: toolbars,
status bars, filler areas, even window decorations and shadows when
using client-side decorations, and of course what you call "content".
In protocol terms, you cannot make a wl_surface visible without a
wl_buffer.

A counter-example on X11: if the window is made bigger than what the
application draws into it (also if the application didn't get to draw
yet but the window is already mapped), the (extra) window area will
contain garbage unless the application tells the X server to fill it
with something. That garbage is usually left-overs of what other windows
from other applications might have left there, or maybe uninitialized
memory, or black in the best case.

In Wayland, there is no such thing as the compositor filling your
window with, say, background color. You, the application, has to
explicitly provide every single pixel you expect to see.

> >
> > xdg-shell extension further defines what sizes you can choose from and
> > when.  
> 
> Now this contradicts what you wrote above ("Not about Wayland").

Yes, sorry. I was trying to give simple answers, when the reality is
complicated and has a lot of "ifs". Choosing a size is actually a
negotiation process between the compositor and the client. A compositor
sets the boundary conditions depending on the window state it is
willing to realize, and the client has to work within those boundaries.
If the compositor uses floating windows, then a normal window usually
doesn't have much restrictions on its size, so you are mostly free to
pick what you want.

All that depends on compositor policy and what kind of window state you
negotiate.

Your toolkit may add its own restrictions, e.g. based on what widgets
you have.

Like Carsten explained, it's actually not that different from X11. X11
has a size negotiation process as well, but the difference is that X11
also allows the client and the WM to fight each other, and you can even
see the fighting on screen if you're unlucky.

> > > > > 3. How can one write a cross-platform application that should behave
> > > > > the same on the different
> > > > > platforms when the developer doesn't have control over window position/size.  
> > > >
> > > > Don't try and position a window. I write applications and I simply don't go
> > > > positioning the window in my own code. I leave it to the system to decide. It
> > > > just so happens my apps work on multiple platforms too because the toolkit
> > > > handles that. I expect the system to provide some sensible window positioning
> > > > of its own. I know full well that this falls apart quickly unless you spend a
> > > > lot of effort doing things like adapting the position you want to the current
> > > > resolution, and avoiding putting your window under other obstacles like
> > > > panels/taskbars and other elements. I just let the WM/compositor handle that.
> > > > If a user has a tiling WM/compositor or a WM capable of tiling modes then
> > > > trying to position your window instantly falls apart and assuming/expecting
> > > > this works is a recipe for pain.  
> > >
> > > I understand.
> > > As I said I believe that the window sizing is based on the window content.
> > > So all I am doing is calling:
> > >
> > > window->Maximize();
> > >
> > > which actually works on all 3 major platforms (Windows, *nix+X, OSX).
> > >
> > > However, my understanding is that it will not work under Wayland.  
> >
> > It should work just fine. On Wayland, the toolkit will ask the display
> > server to switch the window to maximized state. If the compositor
> > agrees, it tells the toolkit so and also tells the toolkit what size it
> > should be on the next window content update.  
> 
> And what happens when the compositor disagree?

Then your window state will remain unchanged, probably.

A compositor can also decide on its own that your window must become
unmaximized some time after it was maximized, or anything else really.

Mind, when I say "a compositor can decide", it is actually a decision or
desire from the end user. But as a Wayland client (application), you
don't see the difference between the compositor and the end user making
policy decisions. The compositor is the proxy for the end user.

> Will I get a very small and narrow window, as explained above? Or
> something else?

That depends on roughly everything.

> Because remember - the content of my window is not created immediately.

What you call "content" is irrelevant here. If a window can be mapped
on Wayland, it already has some content.

> > Third, Wayland does not allow you to find out about other windows or
> > desktop elements that you might want to stay clear of, nor about
> > monitor edges (well... not for this purpose). So it's hard to choose
> > your position properly.  
> 
> OK.
> But I am able to get the monitor size and its DPI, right?

Well... there is generic protocol for some of that, but you really
should not depend on it. It breaks down even in traditional 2D desktop
cases, no need for 3D VR bunnies: many compositors implement fractional
scaling for users that happen to want it. It scales your windows in
ways you as an application do not know.

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/20210528/2099edff/attachment.sig>