On Thu, Sep 1, 2016 at 1:02 PM, Alan Griffiths
<alan.griffi...@canonical.com> 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.
>>From my pov, exposing relative place information is fine. Security concerns do not apply as placement information does not magically enable a client to eat away input. Moreover, even if a client goes to great length to estimate the display boundaries: This only works in the fullscreen case and I cannot think of a scenario where this impacts overall user experience. The app already is the one "owning" the display in fullscreen. Cheers, Thomas > Thoughts and suggestions for the right way forward please. > > > -- > Mir-devel mailing list > Mir-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/mir-devel > -- Mir-devel mailing list Mir-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/mir-devel
