Sorry, I got the impression the meeting was off due to nobody replying
to my meeting replies, and nobody replying to the meeting invite.
Your proposed API is overcomplicated, does not scale and fails to
support shells other than Unity. I do not endorse it, obviously.
It requires exponentially
To help resolve this discussion Thomas Voss called a meeting at 9:00UTC
11-11-2014
Those attending:
Thomas Voss
Christopher James Halse Rogers
Alan Griffiths
Alexandros Frantzis
Andreas Pokorny
Apologies:
Daniel van Vugt
1. We started with a recap over some design goals:
1.1 The server should b
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
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
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
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.
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
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
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: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
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 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
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 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
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
We frequently disagree on the measurement criteria :)
Also, IMHO code reviews provide a more structured place for targeted
discussions. And that helps to focus on facts, with less hand-waiving.
On 10/11/14 12:10, Christopher James Halse Rogers wrote:
On Mon, Nov 10, 2014 at 2:31 PM, Daniel v
On Mon, Nov 10, 2014 at 2:31 PM, Daniel van Vugt
wrote:
Definitely controversial; factually false or easily arguable.
Sounds like a response to one of my merge proposals. So please put
arguments in the code reviews...
It indirectly is, but also in response to some discussion on IRC of one
o
BTW, I do actually agree with half of your points. Just feel that
over-generalising in a discussion like this one is counter-productive.
Because it always is (<- over-generalisation).
On 10/11/14 11:31, Daniel van Vugt wrote:
Definitely controversial; factually false or easily arguable.
Soun
Definitely controversial; factually false or easily arguable.
Sounds like a response to one of my merge proposals. So please put
arguments in the code reviews...
On 10/11/14 10:48, Christopher James Halse Rogers wrote:
Hey all.
We're getting into the meaty bit of client API support I though
19 matches
Mail list logo
