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
On Mon, Nov 10, 2014 at 10:58 AM, Alan Griffiths <
alan.griffi...@canonical.com> 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
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 c
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 a
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
On Tue, Nov 11, 2014 at 12:33 PM, 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
I've already explained why that is untrue. Twice.
On 11/11/14 10:03, Christopher James Halse Rogers wrote:
On Tue, Nov 11, 2014 at 12:33 PM, 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
On Tue, Nov 11, 2014 at 12:48 PM, 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 posi
There is no invalid state possible, providing all attributes have some
default value, and all modifications to an attribute are synchronously
validated (or rejected) on the server side. And it's not even important
if you allow a slight semantic reordering (i.e. "invalid" state):
set_parent(a
So given invalid states are easily rejected by the shell and what mode
it's in, and given it's unrealistic (predicting the future) and
undesirable (scales poorly) to design all future shells behaviours into
separate functions of a client API, I came up with the normalised design
you see today.
On Tue, Nov 11, 2014 at 1:40 PM, Daniel van Vugt
wrote:
So given invalid states are easily rejected by the shell and what mode
it's in, and given it's unrealistic (predicting the future) and
undesirable (scales poorly) to design all future shells behaviours
into
separate functions of a client A
You've forgotten the first point we all agreed on. That is it's up to
the shell to enforce semantics. The rules will change between shells and
between modes of a single shell. So you can't use the compiler of your
client to error-check semantics. They're enforced at runtime according
to the she
Update: "menu" is indeed a proper type now, in the latest design docs
(MIR: Surface Management v0.2 (WIP)). So I'll add that and deprecate the
ambiguous "popover" type.
Turns out when we agreed to scrap the new terminology introduced at the
start of the year and go back to the old version, tha
13 matches
Mail list logo
