Subject: Component clarification

From: Daniel van Vugt <[email-masked]>
Date: Fri, 25 Oct 2013 15:37:17 +0800

OK, let's try again. There seems to be reasonable agreement that at 
least some components are poorly named and therefore confusing. Of 
course, any change requires significant search and replace in the least 
so I'd like to discuss it before any proposals occur.

How about...

mir::surfaces:: --> mir::core::
This component already represents the core platform-independent state 
and implementation code. So rather than call it "surfaces" which 
confuses the numerous existing Surface classes (75% of which are not in 
the "surfaces" component), why not call the component "core" or some such?

mir::graphics::*:: --> mir::platform::*:: or
mir::graphics::*:: --> mir::*::
The whole project is about graphics so we need to stop calling one 
component "graphics". This component already represents the 
platform-specific code. So why not name it "platform" or even remove the 
word "platform"/"graphics" completely and use the actual platform name 
mir::gbm::, mir::android:: etc?

- Daniel

---

From: Kevin Gunn <[email-masked]>
Date: Fri, 25 Oct 2013 09:22:29 -0500

Don't take me wrong, i'm all for making things less confusing.
But to the statement the "whole project is about graphics" isn't completely
true imho, there's also input. To me anything that's related to reading,
writing, manipulating pixel data is worthy of being referred to as graphics.

I'm ok with "state & implementation code" changing from "surface" to
"core". I'm sure others will weigh in.
to be clear, a "surface" is any buffer/container of pixel data that a
app/compositor wants rendered (potentially placed on screen)

also, just challenging (as i really don't know the answer)...but is
mir::gbm heading down a "confusing" path?? is it _really_ gbm specific ? or
is it also specific to other things (drm, kms etc)...?
also...alot of people don't know what "gbm" is outside of graphics stack
junkies (i had to explain what it was to a very savvy person just
yesterday...that when mir team says "gbm" they really mean desktop)
also consider this...you suggested "android"....not "gralloc"...food for
thot
br,kg

On Fri, Oct 25, 2013 at 2:37 AM, Daniel van Vugt <
[email-masked]> wrote:

> OK, let's try again. There seems to be reasonable agreement that at least
> some components are poorly named and therefore confusing. Of course, any
> change requires significant search and replace in the least so I'd like to
> discuss it before any proposals occur.
>
> How about...
>
> This component already represents the core platform-independent state and
> implementation code. So rather than call it "surfaces" which confuses the
> numerous existing Surface classes (75% of which are not in the "surfaces"
> component), why not call the component "core" or some such?
>
> --
> Mir-devel mailing list
> [email-masked]
> Modify settings or unsubscribe at: https://lists.ubuntu.com/**
> mailman/listinfo/mir-devel<https://lists.ubuntu.com/mailman/listinfo/mir-devel>
>

---

From: Daniel van Vugt <[email-masked]>
Date: Mon, 28 Oct 2013 10:41:29 +0800

Yeah, very good point about "gbm". That confused me when I joined to 
project too. It should be called "dri", I think.

And yes, there are some components that are clearly not graphical -- 
input, protobuf. However that leaves "compositor" and "surfaces" in the 
least, which we're saying are not part of "graphics". That's confusing.

- Daniel

On 25/10/13 22:22, Kevin Gunn wrote:
> But to the statement the "whole project is about graphics" isn't
> completely true imho, there's also input. To me anything that's related
> to reading, writing, manipulating pixel data is worthy of being referred
> to as graphics.
>
> mir::gbm heading down a "confusing" path?? is it _really_ gbm specific ?
> or is it also specific to other things (drm, kms etc)...?
> On Fri, Oct 25, 2013 at 2:37 AM, Daniel van Vugt
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>
>     course, any change requires significant search and replace in the
>     least so I'd like to discuss it before any proposals occur.
>
>     How about...
>
>     This component already represents the core platform-independent
>     state and implementation code. So rather than call it "surfaces"
>     which confuses the numerous existing Surface classes (75% of which
>     are not in the "surfaces" component), why not call the component
>     "core" or some such?
>
>     platform-specific code. So why not name it "platform" or even remove
>     the word "platform"/"graphics" completely and use the actual
>     platform name mir::gbm::, mir::android:: etc?
>
>     - Daniel
>
>     --
>     Mir-devel mailing list
>     [email-masked] <mailto:[email-masked]>
>     Modify settings or unsubscribe at:
>     https://lists.ubuntu.com/__mailman/listinfo/mir-devel
>     <https://lists.ubuntu.com/mailman/listinfo/mir-devel>
>
>

---

From: Alexandros Frantzis <[email-masked]>
Date: Tue, 5 Nov 2013 12:34:20 +0200

> project too. It should be called "dri", I think.

What about just "mesa"? I think "mesa" is more recognizable, and
adequately descriptive of the backend's target driver model and APIs.
I don't think Mesa has or will have significant competing non-dri
backends. Having said that, I am fine with either "dri" or "mesa".

Whatever the final choice, I think this is something we are better off
doing early in the cycle (i.e. soon), since it's when we have a window
for non-feature oriented work.

Thanks,
Alexandros

---

From: Thomas Voß <[email-masked]>
Date: Tue, 5 Nov 2013 11:36:34 +0100

> backends. Having said that, I am fine with either "dri" or "mesa".

I would rather prefer dri as opposed to mesa. Although your argument
is technically correct, there is the difference of interface name
(dri) and implementation (mesa) and I tend to favor the interface name
perspective.

> for non-feature oriented work.

+1.

Cheers,

  Thomas

> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/mir-devel

---

From: Alexandros Frantzis <[email-masked]>
Date: Tue, 5 Nov 2013 12:51:03 +0200

> (dri) and implementation (mesa) and I tend to favor the interface name

We are heavily using some Mesa components/interfaces, like GBM, that are
not part of DRI, though.

Thanks,
Alexandros

---

From: Daniel van Vugt <[email-masked]>
Date: Tue, 05 Nov 2013 19:09:43 +0800

I agree with "mesa", but wonder is that still true if we find ourselves 
using Mesa's LLVMpipe on top of fbdev (vesa) later?

---

From: Alan Griffiths <[email-masked]>
Date: Mon, 18 Nov 2013 10:27:31 +0000

This came up again with my resent proposal to move Session related state
to the "surfaces" component.

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

---

From: Alexandros Frantzis <[email-masked]>
Date: Mon, 18 Nov 2013 13:32:41 +0200

> 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

---

From: Kevin DuBois <[email-masked]>
Date: Mon, 18 Nov 2013 17:38:39 -0800

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 <
[email-masked]> wrote:

> https://lists.ubuntu.com/mailman/listinfo/mir-devel
>

---

From: Daniel van Vugt <[email-masked]>
Date: Tue, 19 Nov 2013 09:45:23 +0800

I am "weakly for core", but have a counter-offer...

Why do we need to name this component at all? What if we put all 
clearly-defined server components in:

     mir::server::COMPONENT::

And then any server-specific logic that doesn't have an obvious 
component name to live in can go in:

     mir::server::

All this talk of data models is an over-complication, I feel. Let's just 
call it what it is; server. And any components which can be clearly 
defined in themselves can still be named under that.

---

From: Alan Griffiths <[email-masked]>
Date: Tue, 19 Nov 2013 14:18:32 +0000

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
>
> 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
> <[email-masked]
> <mailto:[email-masked]>> wrote:
>

---

From: Alan Griffiths <[email-masked]>
Date: Tue, 19 Nov 2013 14:20:29 +0000

> misinterpreted as implying that it /is a/ scenegraph (rather than /has

we've *seen* it misinterpreted

---

From: Thomas Voß <[email-masked]>
Date: Tue, 19 Nov 2013 15:31:12 +0100

+1.

> 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

---

From: Kevin Gunn <[email-masked]>
Date: Tue, 19 Nov 2013 13:03:53 -0600

+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ß <[email-masked]>wrote:

> "scene"

---

From: Kevin DuBois <[email-masked]>
Date: Tue, 19 Nov 2013 11:30:52 -0800

+1 to scene from me too

On Tue, Nov 19, 2013 at 11:03 AM, Kevin Gunn <[email-masked]>wrote:

>> a/
>> more

---

From: Daniel van Vugt <[email-masked]>
Date: Wed, 20 Nov 2013 09:52:42 +0800

I understand "scene" and the word did cross my mind too, but I think it 
would be better to simply name things "server" because the reality is 
that it's a server-side implementation component.

Also, in Unity8-land, Unity is taking over "scene" responsibilities soon 
so it makes less sense then to name yet more things "scene" in Mir.

I think we're all getting too caught up in abstract concepts and models, 
and forgetting how to communicate effectively with 
whoever-reads-the-code-next.

On 20/11/13 03:30, Kevin DuBois wrote:
> +1 to scene from me too
>
>
> On Tue, Nov 19, 2013 at 11:03 AM, Kevin Gunn <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     +1 for me too....
>     On Tue, Nov 19, 2013 at 8:31 AM, Thomas Voß
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>         <[email-masked]
>         <mailto:[email-masked]>> wrote: