Component clarification

Kevin DuBois kevin.dubois at canonical.com
Tue Nov 19 19:30:52 UTC 2013


+1 to scene from me too


On Tue, Nov 19, 2013 at 11:03 AM, Kevin Gunn <kevin.gunn at canonical.com>wrote:

> +1 for me too....
> as much as i could have gotten behind diaroma...let's use scene
>
>
> On Tue, Nov 19, 2013 at 8:31 AM, Thomas Voß <thomas.voss at canonical.com>wrote:
>
>> 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
>> >
>>
>> --
>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/mir-devel/attachments/20131119/56b7dc86/attachment.html>


More information about the Mir-devel mailing list