[PATCH] Introduce set_size_hints xdg_surface request.

[Bill Spitzak]

On 08/08/2014 12:00 AM, Pekka Paalanen wrote:
> Bill, you again managed to drop people from CC. Please do not do that.

I am not sure what is up with Thunderbird here. The problem was that I 
responded to my own post. In addition it refuses to show reply-all or 
reply-to-list to any of my git send-email patch sets. I have tried 
manually adding the list id and nothing makes a difference. I will try 
to make sure the cc list is copied (it is working for this reply...)

> On Thu, 07 Aug 2014 12:43:17 -0700
> Bill Spitzak <spitzak at gmail.com> wrote:
>
>> On 08/07/2014 07:18 AM, Jari Vetoniemi wrote:
>>   >> What is the default value of these hints?
>>
>> I think you could get away with defaulting the minimum to be about
>> 100x100. I think that is sufficient to get clients to work ok and it is
>> small enough to encourage them to set this rather than relying on the
>> default.
>
> I really don't think we want to encode that into the protocol
> specification. "Unset" is the right answer here.

Sorry that was poorly stated. What I meant is that the implementation 
can just treat "unset" as 100x100 (or any other value it wants). I don't 
think it needs to do anything more complicated for unset values, since 
any such complication should be something the client can communicate. 
This means that the implementation does not need any "unset" value, it 
can just init the data to 100,100 (or whatever).

It might help if the tiling window manager treated the minimum size as 
the smaller of the surface's current size and it's declared minimum. 
That would allow the default minimum to be much larger.

>>>> How does this interact with the protocol sequence to decide the initial
>>>> size of a window before it gets mapped?
>>
>> These should have no effect. The client is free to supply sizes outside
>> the range it claims. And the compositor is free to request them. It is
>> only a hint.
>
> Not exactly always.
>
> And yes, like in my rephrased question, there is very definitely an
> interaction, or you may see a size change glitch on opening new windows.

The tiling window manager has to send a configure event with the desired 
size before showing the surface. Only the window manager knows what size 
it wants the surface. In a correctly working system it can block the 
update until all the clients respond with resized surfaces (obviously 
there are timeouts and dead clients, but that problem is true of all 
changes to the window layout, not just the ones due to the minimum size 
changing).

I think this sequence works:

1. Client creates wl_surface and xdg_shell_surface
2. Client sends minimum size
3. Client creates buffer at the size it wants, draws, and commits it
4. Compositor probably cannot handle that size. It sends configure event 
to the client (and all the other clients since the mapping of the new 
surface probably changed things). It could sent the configure event 
before the commit if it can figure it out without the buffer size.
5. Client resizes the buffer to new size, draws, and commits it
6. Compositor redraws the screen after all the clients respond or time out.

Though it seems like the first drawing is a waste of time, I don't see 
any way to avoid it. The compositor must have a buffer, because it needs 
a fallback if the client fails to respond to the configure request 
before the timeout. And currently this is where the desired size (which 
may be different than the minimum) is sent. Also any other scheme will 
needlessly slow down non-tiled window management by requiring a 
round-trip before the client can draw the first surface.