Client API philosophy

[Daniel van Vugt]

On the second issue of client API design, it's useful to point out why 
the menu example is not a good argument:

1. Depending on your shell, and its current mode, a "menu" might not 
have a relative position dictated by the window position, but get 
moved/modified elsewhere on the screen. Think about phones where long 
menus/combos get converted to a wheel/widget in the centre of the screen 
(mostly phones).

2. Relative position is useful to other window types too. For example 
the decorations-next design of title bars, but also embedded GL windows 
or accelerated video in a browser. So with multiple features requiring 
relative placement, you propose each new feature gets a new client 
function, which is mostly redundant with the others? That's crazy for 
three reasons:
   (a) Redundancy in the API is unwanted effort, particularly for 
maintenance. It scales poorly.
   (b) Each function, by its name, is tied to a window type (e.g. 
"menu") and so could easily become deprecated as desired 
types/functionality changes.
   (c) Your proposed API that ties a "menu" to (x,y) now has 
unused/ignored parameters in phone (or other) shells that ignore the 
(x,y) for menus (see #1 above).


On 11/11/14 09:33, Daniel van Vugt wrote:
> We are actually in violent agreement on "policy" and conflating two
> different issues. So please, let's separate them :)
>
> It is indeed up to the server/shell to dictate policy, particularly as
> it can and will vary between shells/modes of a shell. Anything invalid
> is returned as an error to the client API, or in the form of a
> non-blocking API:
>
>    1. asynchronous set feature A = B
>    2. optional wait and get feature A, and check it was changed to B or
> something else dictated by shell policy.
>
> What we must not do is try to enforce policy via client function
> prototype design. Because policy changes not just between shells, but
> even between modes of a shell (e.g. we aim to unify Unity8 desktop with
> touch I think).
>
> The confusion here is coming from some people thinking that a flexible
> API prevents strong enforcement of policy. It does not.
>
> P.S. "menus" are explicitly not a window type right now (as copied from
> the WM design docs). So it's possibly assuming too much to mention the
> the word "menu" in the client API. Although we possibly could - rename
> popover?
>
>
> On 10/11/14 17:58, Alan Griffiths wrote:
>> On 10/11/14 03:31, Daniel van Vugt wrote:
>>>
>>> Sounds like a response to one of my merge proposals. So please put
>>> arguments in the code reviews...
>>
>> There's a good reason to discuss this outside of a specific code review:
>> we need to agree the "big picture".
>>
>> There is an apparent disagreement about the approach to window
>> management policy and that affects the review of any and all MPs in this
>> area.
>>
>> I've always understood the intent to be that Mir enables shells (in
>> general and specifically unity8) to implement policies about how things
>> should be presented. It is far easier for a shell to provide a policy
>> around, say "menus" if it is asked to "show a menu" than if it is asked
>> for a window, then asked to "parent" it, then asked to position it, etc.
>> With this approach there is never any point at which the server knows
>> what the client intends.
>>
>> If we intend to push the presentation policy out to the client toolkits
>> then they will provide inconsistent (a.k.a. incorrect) policy
>> implementations. (Especially if, as we should hope, there are multiple
>> shells written using the Mir library that implement policies
>> differently.)
>>
>>
>>
>