Component clarification

Thomas Voß thomas.voss at canonical.com
Tue Nov 19 14:31:12 UTC 2013


On Tue, Nov 19, 2013 at 3:18 PM, Alan Griffiths
<alan.griffiths at canonical.com> wrote:
> I think the natural domain name is "scene".
>

+1.

> 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".
>
>

Seconded, scene feels natural to the problem domain that elements in
the namespace help solving.

Cheers,

  Thomas

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



More information about the Mir-devel mailing list