Client API philosophy

[Daniel van Vugt]

May I ask if you have a better design for any functionality, please 
demonstrate it. You don't have to go to the trouble of a working merge 
proposal... Just suggest function prototypes.

Then there's less imagination required, less confusion that we're 
arguing when we're agreeing, and more solid reasoning.


On 11/11/14 09:48, Daniel van Vugt wrote:
> 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.)
>>>
>>>
>>>
>>
>