[PATCH] Introduce set_size_hints xdg_surface request.

[Pekka Paalanen]

On Thu, 7 Aug 2014 17:18:54 +0300
Jari Vetoniemi <mailroxas at gmail.com> wrote:

> > What is the default value of these hints?
> 
> I would propose -1 as default, meaning unset.
> Compositor has to deal with not knowing the minimum size, preferably
> this would mean though that the client can be set to any valid size.
> 
> > When is the client expected to send this? Can this be sent before
> > the window gets mapped? After the window was unmapped?
> 
> I would say this hint could be sent any time after surface object is created.
> 
> > How does this interact with the protocol sequence to decide the initial
> > size of a window before it gets mapped?
> 
> If the maximum was less than initial size, this would need thinking.
> For now it seems though that maximum might go away?

My main question here was, how does the protocol sequence look like?

A client creates a wl_surface and a xdg_surface for it. What does the
following protocol sequence look like, when negotiating the initial
window size, leading to mapping the window the first time?

Does the server send a configure event immediately as a reply to
creating the xdg_surface? If yes, does the compositor send a new
configure event after the client has sent the size hint request?

If the client sends the request to create xdg_surface immediately
followed by the request to set size hints, how does the client know if
the next configure event it receives is before or after the
compositor saw the size hint? Does it even matter?

Or do you require a round-trip: the client must wait for the first
configure event before sending the size hints, so that it knows the
next configure event is with size hints applied?

(I would like to avoid round-trips whenever sanely possible.)

> Needs further discussion.
> 
> > Making surface state double-buffered is desired for all state that
> > immediately affects the surface's presentation. However, these are
> > hints and do not change how the surface is presented; they change what
> > sizes the compositor may ask for in configure events. It that sense, it
> > is not necessary to make this state double-buffered, and I think not
> > double-buffering (not demanding a commit) will make it easier to use
> > and also to define how it works with the initial size negotiation.
> 
> I agree with this, I don't see any reason for this to be
> double-buffered either to be honest.

Otherwise seems ok AFAIU.


Thanks,
pq