What we do and don't expose to client toolkits

[Daniel van Vugt]

A relative {x,y} would make sense and be much simpler than the currently 
over-engineered "attach to a rectangle". In Xmir and toolkits we tend to 
see empty rectangles being used:
    MirRectangle placement = {dx, dy, 0, 0};
already. It should have been a simple relative {x,y} from the beginning...


On 01/09/16 19:02, Alan Griffiths wrote:
> When clients toolkits provide hints to place child surfaces using the
> existing functions:
>
>     mir_surface_spec_attach_to_foreign_parent();
>     mir_connection_create_spec_for_tip();
>     mir_connection_create_spec_for_menu(); or the proposed,
>     mir_surface_spec_set_placement()
>
> the toolkit wants to know where the child surface actually ends up in
> order to render appropriately.
>
> We currently have a policy not to provide any location information to
> clients, so I want to be sure that I don't propose anything controversial.
>
> In discussion with Chris he suggests that sending a
> PlacementRelativeToParent{dx, dy} message is the right solution.
>
> Doing this opens up an opportunity for clients to:
>
>     1. probe the display boundaries using dummy placement requests. (The
>     point is to provide the location before they render.)
>
>     2. parent (and place) everything they do on a fullscreen surface
>     (which they can conceal from the user). It does limit them to
>     surface types that can be parented.
>
> Thoughts and suggestions for the right way forward please.
>
>
>