[PATCH weston] xdg-shell: Make stable

[Bill Spitzak]

On 08/25/2014 11:25 PM, Pekka Paalanen wrote:

>> No, please make it impossible for a client to rely on events being
>> echoed in response to requests. Otherwise toolkits will rely on this and
>> Wayland will become a synchronous protocol.
>
> Did you understand that this is not an additional round-trip, but it
> conflates to the original roundtrip?

I am trying to get rid of the "original" round trip.

The client should create the surface and start drawing a buffer for the 
size it wants, with no round trip. Of course the compositor may not like 
that size and will send a configure event rather than show the surface. 
But there are a million other reasons the compositor may send a 
configure event and they all cause a drawing to be "wasted".

> Yes, I agree counting events is a bad approach, but I also wanted to
> list all options coming to my mind. Think of it as a trap, if you wish.

Yes, counting events is a bad approach.

Distinguishing zero and one is counting.

>> If you want to insist that the surface size always obey the size hints,
>> make it a protocol error for a client set them to incompatible values.
>
> I do not understand you.

I am worried about a compositor doing this:

- Client has a 100x100 surface
- Client sends a size limits that says the minimum is 200x200
- Compositor "helpfully" echoes back a 200x200 configure events.

Some of the text in previous emails, about configure events being sent 
in response to size hints, led me to worry that this will be done. It 
should not do that ever because the client is already changing it's size 
(lets say to 250x250), since the client already knows that the current 
100x100 size is too small for it's own size hints. It will have to 
ignore this configure event. But then it will also ignore one from a 
tiled window manager that actually cannot make the window 250x250 and is 
trying to keep it 200x200!

The way a tiled window manager should work is to arrange windows based 
on an "actual" size range that is the one in the hints extended to 
include the current size of the surface. In the above example that range 
still starts at 100, so the current tiled layout is ok. If the client 
then resizes the surface to 250 then the range now starts at 200 and a 
relayout is triggered.

Yes that may make it send a configure event to the client telling it to 
use another size. However it is also going to send configure events to 
other clients (all the ones in the same row or column of the tiled 
layout). They all have to redraw, so the fact that this one draws one 
extra time is not a big deal.

The "protocol error" was my response if people think there is something 
wrong with clients "disobeying" their own size hints. I think that is ok 
but you could make setting a surface size is set that does not match the 
size hints be a protocol error.

> Also, size is not the only piece of state in a configure event. I don't
> think we can avoid the one roundtrip on window creation.

The roundtrip can be easily avoided in cases where the client happens to 
pick a configuration the window manager likes. If that is the majority 
of cases then a round trip is saved in the majority of cases. And I 
suspect for overlapping window managers and popup menus that will be the 
majority of cases.