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 more effort and maintenance, to achieve a less
flexible result. I can't stop the team from outvoting me, but I will not
implement an inferior design that requires unbounded ongoing maintenance
(supporting new shells, new types, new semantics) when a superior design
that supports all use cases from day 1 and has zero ongoing maintenance
is already proposed.
On 11/11/14 22:29, Alan Griffiths wrote:
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 be in control of "policy"
1.2 It should be easy to validate use of the client API
Thomas noted that he saw no need to support re-parenting - there was no
disagreement.
We discussed the several design approaches being discussed - including
the "parenting" proposals from Daniel and the "two-stage-surface-create"
proposal from Chris and variations from various discussions. These were
assessed against the needs of the user of the client API and the needs
of the server to decide presentation policy.
Consensus was reached around the following:
For each type of surface there should be a corresponding "builder" type.
We used creation of a "menu" to illustrate the canonical form of surface
creation (note the names here are illustrative, not prescriptive)...
// allocate a builder with all required parameters
MirSurfaceBuilder* menu_builder =
mir_connection_allocate_menu_builder(connection, /* any required
parameters (e.g. parent) */);
...
// set any optional attributes
mir_surface_bulder_set_XXX(menu_builder, xxx);
// Finally, create the surface
MirSurface* surface =
mir_surface_bulder_create_surface_sync(menu_builder);
This approach had the following advantages:
1. The type of surface is determined explicitly
2. Provision of required parameters is validated at compile time
3. MirSurfaceBuilder and MirSurface are opaque types
Note that discovering new "required" parameters is an API break and this
approach ensures affected code is identified at compile time.
Re the "parenting" branches: "parent" is only ever provided as part of
builder creation (and supplied to the server at surface creation time).
Re-parenting isn't to be supported. These branches need reworking
accordingly.
Actions:
Chris: to update his branch to have a separate builder object. (This
also addresses concerns about functions that behave differently between
pre-realize and post-realize.)
Alan: write minutes
--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/mir-devel
