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.
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: set_parent( me, parent) set_relative_ position( me, parent, 17, 34) set_type( menu) realise( me)
mir_surface_
mir_surface_
mir_surface_
mir_surface_
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.