MDG Default Line Color

[Paolo F Cantoni]

I thought previously (and reiterated by qwerty in his Inside EA eBook), a "-1" in the LineColor in t_connector would make the arc take the default colour in the MDG (bordercolor="nnnnn").

We are creating some arcs via automation (SQL) and even though we set LineColor=-1 in the LineColor column, they still show black.  I note, that if we drag the same stereotype off the toolbox onto the diagram, the value in the MDG is set into the LineColor column, not -1.  The t_diagramlinks style setting shows: "Color=-1;" in all cases for that arc.

Can someone definitively tell me what's the specification?  I'm using build 1304 - but it also occurs under v12.

Is the specification true for ALL arc types or differs depending on the type?

TIA,
Paolo

[qwerty]

Honestly, I have difficulties following your steps. Alas, the LineColor is the global setting. If you change that, all connectors will take that color - except: a diagram uses Color override which is stored in t_diagramlinks.

q.

[Paolo F Cantoni]

Honestly, I have difficulties following your steps. Alas, the LineColor is the global setting. If you change that, all connectors will take that color - except: a diagram uses Color override which is stored in t_diagramlinks.

q.

Sorry about that, my bad.  But your response may have the basis of, at least, explaining the behaviour. 

With vertices, setting the line color to default (whether at the t_object or t_diagramobject level) will set the line to the colour shown in the MDG definition.  So for example, if I make my Classes blue and my Activities red, setting each to -1 will generate the appropriate border colours on the diagram.  Actually some testing reveals some EAUI.  If the BorderColor value in the MDG is NOT 0 (or -1) then the birder color will be set correctly (regardless of the Line color setting in the [Ctrl+F9] dialog).  If it is -1 then it is set to the value in the [Ctrl+F9] dialog.  If it is 0, then it is NOT set to BLACK, but to the default value!

With arcs, that doesn't happen.  The BorderColour setting in the MDG doesn't seem to have ANY effect.  The default colour is ALWAYS the value of the Connector Line Colour in the [Ctrl+F9] dialog.

For consistency (and to provide the ability to control the diagram rendering), there should be a hierarchy:
Project default, Metatype (MDG or Local) Default, Element Default

The colour value to be rendered could then be CONSISTENTLY determined:  Check element, check metatype (from MDG or locally defined), check project (in that order).

Thoughts?

Paolo
[Edit:  There is NO project default - it's an instance Default.  EACH EA instance sets it's own set of colour defaults that it applies across all the repositories that it opens.]

[Eve]

That's a simplified view of the hierarchy.

In order of priority.
Set color in shape script (for explicitly drawn shapes)
Diagram Object Color
Set color in shape script (if calling drawnativeshape)
Element Default Color
Stereotype color (Since v10. Before that this was set as element color on creation)
Element Group Style color (fill only, if enabled, not configurable)
User color setting
EA.exe default (If user has never set a color)

There may be some exceptions to that, or the "-1 is default" that are needed to maintain consistency between builds. (eg. Treating 0 as default because otherwise thousands of users would get black objects on upgrading)

[KP]

Not forgetting auto-color legends which fit into the list as below:

That's a simplified view of the hierarchy.

In order of priority.
Set color in shape script (for explicitly drawn shapes)
Auto-color legends
Diagram Object Color
Set color in shape script (if calling drawnativeshape)
Element Default Color
Stereotype color (Since v10. Before that this was set as element color on creation)
Element Group Style color (fill only, if enabled, not configurable)
User color setting
EA.exe default (If user has never set a color)

There may be some exceptions to that, or the "-1 is default" that are needed to maintain consistency between builds. (eg. Treating 0 as default because otherwise thousands of users would get black objects on upgrading)

[qwerty]

It looks like Simon is just talking about elements, but Paolo is talking about arcs.

q.

[qwerty]

There is NO project default - it's an instance Default.  EACH EA instance sets it's own set of colour defaults that it applies across all the repositories that it opens.

Personally, I think this is a design flaw to allow individual overrides. That will undermine a common view of the model (and make documentation inconsistent amongst different users).

q.

[Paolo F Cantoni]

There is NO project default - it's an instance Default.  EACH EA instance sets it's own set of colour defaults that it applies across all the repositories that it opens.

Personally, I think this is a design flaw to allow individual overrides. That will undermine a common view of the model (and make documentation inconsistent amongst different users).

q.

As I've alluded to before:  "You might well think that, I couldn't possibly say that..."   

Paolo

[Paolo F Cantoni]

It looks like Simon is just talking about elements, but Paolo is talking about arcs.

q.

Indeed I am!  AND I am explicitly talking about the BorderColor, no other property at this stage.  If all such properties are subject to the same hierarchy, then good, else please indicate deviations.

Was I that unclear?

Paolo

[Eve]

Neil, thanks. I had forgotten that.

Yes, I was aware that Paolo was talking about links. I generalized it because the order is/should be the same apart from the group style not existing for connectors. I think the error was in my wording.

qwerty and Paolo, while there are options in EA that I would put in that category, I don't include the color. If nothing else, it's reasonable to allow a high contrast view for a vision impaired model user. Beyond that, is it wrong for different users to use defaults that are more visually appealing to them. Can you even prove that you see the same color as I do? (Different monitors, physiological differences etc)

[qwerty]

I would concur if that were just the screen rendering. But print/export rendering take the same colors. I think there are worse things to fix than this, but it's still one of the ugly parts (from a system design view).

q.

[Paolo F Cantoni]

FWIW, I'm not suggesting there shouldn't be a user specific customisation.  My beef is that it needs to be part of a coordinated hierarchy of defaults.  It's haphazard and inconsistent at present.

From an enterprise perspective, you need to be able (if necessary) to enforce consistency.

Paolo

[Glassboy]

From an enterprise perspective, you need to be able (if necessary) to enforce consistency.

I find myself siding with Simon.  I work with someone with no colour vision and I play board games with 3 people who have different types of red/green colour-blindness.  People with with colour vision which is regarded to be "normal" perceive the same colour to be different colours depending on what borders the colour or the size or the size of the coloured area.  The cultural meanings overlaid on colour differ massively between cultures.

Colour is inherently an inconsistent communicator of information, outside of an individual's own visual idiolect.

[qwerty]

From a personal/human standpoint that's pretty ok. But try telling that to marketing people that have spent zillions on a CI. And - if you try to create documents that everyone can read, you end up with an extra braille, one for red/green blindness, one of people with aged eyes (like me) in addition to what "normal" people can read. Sick as it is, but when inclusion starts excluding "normal" people it's getting counter-productive.

q.

[Glassboy]

It's actually easy to produce knowledge representations that work for a huge range of the human population.  The problem is that most people perceive themselves as a) normal, and b) the focal point of the design parameters.