Code review comment for lp:~vanvugt/mir/parenting-client-api

I didn't look for programming or style errors.

At a high level goal though im told our target is to enable menus next week and so this branch wont be enough as it lacks child surface positioning.

Of course it would be possible to implement menus with this branch and a little more:
mir_surface_set_parent(me, parent)
mir_surface_set_relative_position(me, parent, 17, 34)
mir_surface_set_type(menu)
mir_surface_realise(me)

It raises some debate: Can parents be changed? What happens if I set a relative position but am parented? Should mir_surface_set_parent and set_relative_position be combined? Should you be able to set a parent without a relative position! What should these functions be called? Is setting a menu type without a parent an error or does the shell simply fail to change type for you? Does the creation of these sort of attribute dances effectively mean creating an implied Window Management protocol which starts to look very Xey.

Ultimately I think all these questions do have answers but they are not very interesting. Its much more interesting to have menus next week and I think chriss proposal of mir_surface_create_menu, etc family of functions lets us move quickest. mir_surface_set_parent, etc, could be added later.