What we do and don't expose to client toolkits

[Alan Griffiths]

On 06/09/16 00:41, Christopher James Halse Rogers wrote:
>
>
> On Tue, Sep 6, 2016 at 2:21 AM, Alan Griffiths
> <alan.griffiths at canonical.com> wrote:
>> On 02/09/16 15:44, Alan Griffiths wrote:
>>> On 02/09/16 15:42, Thomas Voß wrote:
>>>> 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.
>>> Why would you think it only work in the fullscreen case?
>> there was an IRC conversation to sort this out between myself William
>> and Thomas.
>>
>> I think the resulting consensus was:
>>
>> 1. Mir will constrain the placement anchor of the aux_rect to the
>> parent surface. I don't think we agreed exactly how (e.g. do we
>> "clip" the rect? What happens if there is *no* intersection?)
>>
> This is easy. The client knows all the information required to ensure
> this, so if any part of the placement anchor is outside the parent
> anchor, we fail the request.

1.1 Things are asynchronous - so the client doesn't know in advance the
state the server will see.
1.2 I should have stated explicitly: we favoured making this a
post-condition, not a pre-condition.

>
>> 2. Mir will constrain the the offset placement anchor to the parent
>> surface. Again I don't think we agreed how. (Slide it horizontally
>> and/or vertically the minimum amount?)
>>
> If any part of the offset placement anchor is outside the parent
> surface, we fail the request. ☺

2.1 Things are asynchronous - so the client doesn't know in advance the
state the server will see.
2.2 I should have stated explicitly: we favoured making this a
post-condition, not a pre-condition.

This also leads me to wonder how much use the server should make of
placement information when the parent surface is resized or moved. On
Unity7 tips and menus typically disappear in these cases. But with Mir
the client doesn't know about anything about position - even moves.