On Tue, Nov 19, 2013 at 3:18 PM, Alan Griffiths <alan.griffi...@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.frant...@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@lists.ubuntu.com >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/mir-devel > > > > > -- > Mir-devel mailing list > Mir-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/mir-devel > -- Mir-devel mailing list Mir-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/mir-devel
