Code review comment for lp:~vanvugt/mir/wait-result

Ah, right.

My feeling is that this use in particular could be better done on the callback-side by providing an aggregate surface event with all the relevant new state at once. Morph then becomes a set_state-like void call.

This also cleans up server-driven changes somewhat - for example, we can send the client can an event containing both state_fullscreen and the new surface size.

Presumably the server will be sending the updated state anyway? The client can't actually rely on the values matching new_spec even after mir_wait_for_result(mir_surface_morph(surface, new_spec)) returns true, because the server may have already sent - and the client event thread already processed - new attributes.

My feeling is that any client code that responds to attributes that isn't being directly driven from a surface event callback is fundamentally incorrect, and we shouldn't make it appear as though you can safely do anything else.