<div dir="ltr"><div>These are a few questions mainly directed to Wayland developers. I greatly appreciate any insight into how Wayland is supposed to work.<br></div><div><br></div><div>1. The wl_surface.frame request gives you a hint as to when it is best to supply Wayland with new content for a surface. I wonder if it has any use in the GUI environment? I implemented redrawing such that this callback is used, but now re-implemented it without this callback as it seems to only complicate things without any benefit. On the other hand, Gnome apps seem to be using it (gedit is one example), so I wonder if I am missing something and the callback is actually there to drive the re-drawing cycle, for example?<br></div><div><br></div><div>2. xdg_surface.ack_configure. What does this ack_configure actually mean for the server in these scenarios of a window resize operation: suppose there was toplevel.configure for size 100x100 and then<br></div><div>2.1 we ack_configure'd it, but then committed the surface with a new 200x200 buffer. <br></div><div>2.2 or we did not send ack_configure for this serial at all and committed the surface with the same buffer as previously (no change in size).</div><div>Should we expect another toplevel.configure for the new size in each case following the "unexpected" surface commit? Does the protocol necessitate another toplevel.configure in either case?<br></div><div><br></div><div>3. Initial xdg_toplevel.configure.<br></div>Does the protocol require the server to send the initial toplevel.configure with the size 0x0 after the creation of that xdg_toplevel? It doesn't seem to say so in the protocol's xml files, but *not* waiting for that configure event and attaching a buffer to a surface prior to sending any xdg_surface.ack_configure seem to contradict the protocol ("the client must make an ack_configure request sometime before the commit").</div>