Component clarification

Alan Griffiths alan.griffiths at canonical.com
Tue Nov 19 14:18:32 UTC 2013


I think the natural domain name is "scene".

It was the first suggestion and was only doubted because we've it
misinterpreted as implying that it /is a/ scenegraph (rather than /has
a/ scenegraph).

In the absence of a clearer, natural name I think we should go with
"scene" and educate people that think it is synonymous with "scenegraph".

On 19/11/13 01:38, Kevin DuBois wrote:
> I'm also slightly against 'core', just because people will think its
> more important than it is
>
> scene, model, and model_controller has connotations to me, maybe
> mir::diaroma?
>
> Pretty unloaded word... To me, it means 3d objects put in a box for
> the purposes of displaying. If no one supports that though, 'scene'
> would be my preference.
>
>
> Cheers,
> Kevin
>
>
> On Mon, Nov 18, 2013 at 3:32 AM, Alexandros Frantzis
> <alexandros.frantzis at canonical.com
> <mailto:alexandros.frantzis at canonical.com>> wrote:
>
>     On Mon, Nov 18, 2013 at 10:27:31AM +0000, Alan Griffiths wrote:
>     > This came up again with my resent proposal to move Session
>     related state
>     > to the "surfaces" component.
>     >
>     > On 25/10/13 15:22, Kevin Gunn wrote:
>     > > I'm ok with "state & implementation code" changing from
>     "surface" to
>     > > "core". I'm sure others will weigh in.
>     >
>     > I'm not convinced that it says "semantic data model" but neither
>     does
>     > "surfaces". But what do folks think about "core"?
>     >
>     > Strongly For/Weakly For/Weakly Against/Strongly Against?
>
>     I think the term "core" is at the same time too vague and too strong.
>     It's too vague because it doesn't describe what the "core"
>     component of
>     mir contains. It's too strong because "core" forces us to think in
>     terms
>     of a special core component and other non-core components, which I
>     don't
>     think is appropriate for our architecture.
>
>     My vote is on the stronger verge of "Weakly Against"; I am sure we
>     could
>     get used to it, but I think we can do better. Some alternatives
>     mentioned on IRC:
>
>     mir::scene
>     mir:model
>     mir::model_controller
>
>     Thanks,
>     Alexandros
>
>     --
>     Mir-devel mailing list
>     Mir-devel at lists.ubuntu.com <mailto:Mir-devel at lists.ubuntu.com>
>     Modify settings or unsubscribe at:
>     https://lists.ubuntu.com/mailman/listinfo/mir-devel
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/mir-devel/attachments/20131119/30566823/attachment.html>


More information about the Mir-devel mailing list