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.)
--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/mir-devel
