Code review comment for lp:~alan-griffiths/mir/first-pass-of-surface-spec-modification

> needs-info:
> 1) Shouldn't this take a MirSurfaceSpec* instead of of a MirSurface*?
> 31 +void mir_surface_set_title(MirSurface* surface, char const* name);

No, this is a signature change (dropping the wait handle) to an existing method that's a "convenience wrapper" around the MirSurfaceSpec calls needed to change a surface title. (C.f. lp:~vanvugt/mir/rename-api/+merge/252864/comments/628924.)

> 2) Is it (or will it be) possible to construct a MirSurfaceSpec that's
> invalid? For instance, if we have a mir_surface_spec_set_size(..., int x, int
> y), and someone tries to morph a tooltip to a tooltip that spans multiple
> monitors that seems to violate the meaning of the types in the spec document.
> It might make sense to indicate to the client that its request was "flat-out
> rejected forever", instead of "accepted as something that the server will try
> to apply when appropriate".

That's a poor example of a MirSurfaceSpec that's invalid: How is that any different from the existing scenario of a "someone" requesting a tooltip that spans multiple monitors without a modification? The server knows what monitors are attached at the time it processes the request (and what "shell space" exists on the monitors) and sizes the surface accordingly.

A better example would be creating a MirSurfaceSpec for changes and then calling mir_surface_create_sync() - which will then abort because the surface has no type.