Sparx Systems Forum
Enterprise Architect => Automation Interface, Add-Ins and Tools => Topic started by: Paolo F Cantoni on September 09, 2016, 12:16:58 pm
-
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
-
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.
-
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.]
-
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)
-
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)
-
It looks like Simon is just talking about elements, but Paolo is talking about arcs.
q.
-
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.
-
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
-
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
-
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)
-
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.
-
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
-
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.
-
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.
-
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.
-
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
What's the beef then? There is a coordinated hierarchy of defaults. It's just deeper than you initially thought.
You can enforce consistency when required. You have always been able to set a color on the elements to override the user defaults. Both html and document generation support an option to set the diagram theme used for generation. (Perhaps that could be extended to printing as suggested by qwerty, it's not something I see as particularly important) Overriding the user default. Version 13 also adds the capability to set a specific theme on a diagram, again overriding the user defaults. Any of these can be used to enforce consistency where needed.
-
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.
That's NOT my point. As I said, each user should be allowed to make their changes. My point is there is NO project wide consistency that allows the enterprise to say: In this repository, unless you personally make changes, things shall look like... I can make changes to the default renderings in one repository for whatever reason - say default connector colour green. Those changes will apply to another repository that I didn't intend the changes to apply to.
@Simon, it's NOT about changing an individual diagram; it's about providing consistency for diagrams that haven't been modified for some specific reason. Its also about the inconsistency between what I can do for vertices and what I can't do for arcs - define, reliably, the color of the arc from the MDG. In our repository, the default line colouring for vertices is defined in the MDG - not in the repository. This means that if we decide to change the rendering of a vertex, it changes everywhere it hasn't been overridden. I can't do that for arcs. This whole thing has ONLY (really) been about that. See my original post. When you have, literally, tens of thousands of diagrams control over consistent rendering becomes important. You attempt ti abstract the rendering to the greatest scope you can.;
Just as there is a User default for diagrams (on a per repository basis), there needs to be a repository wide and user default for rendering settings.
Paolo
-
I can make changes to the default renderings in one repository for whatever reason - say default connector colour green. Those changes will apply to another repository that I didn't intend the changes to apply to.
...
This means that if we decide to change the rendering of a vertex, it changes everywhere it hasn't been overridden. I can't do that for arcs. This whole thing has ONLY (really) been about that. See my original post. When you have, literally, tens of thousands of diagrams control over consistent rendering becomes important.
...
Just as there is a User default for diagrams (on a per repository basis), there needs to be a repository wide and user default for rendering settings.
Paolo
1. You can't do that. There has never been an option to change the rendering defaults in a repository. Those options are located in the user options, and the only options in EA that depend on model and user are default user diagrams when security is enabled.
2. Obviously, you weren't clear enough with your problems. Perhaps not starting off by talking about sql updates would help... It may just be that the v10 change to move stereotype color from being applied on creation to being an extra default layer didn't apply to connectors (contrary to my belief)
3. As I said, there is a "User default for diagrams (on a per repository basis)". If you feel that a model level default is something that will benefit all EA users, feel free to submit a feature request.
-
That's NOT my point. As I said, each user should be allowed to make their changes. My point is there is NO project wide consistency that allows the enterprise to say: In this repository, unless you personally make changes, things shall look like... I can make changes to the default renderings in one repository for whatever reason - say default connector colour green. Those changes will apply to another repository that I didn't intend the changes to apply to.
Beyond being able to define a default theme your suggestion is quite dangerous as it could be used to a) destroy information inside the repository, b) prevent some users from perceiving elements on diagrams.
-
That's NOT my point. As I said, each user should be allowed to make their changes. My point is there is NO project wide consistency that allows the enterprise to say: In this repository, unless you personally make changes, things shall look like... I can make changes to the default renderings in one repository for whatever reason - say default connector colour green. Those changes will apply to another repository that I didn't intend the changes to apply to.
Beyond being able to define a default theme your suggestion is quite dangerous as it could be used to a) destroy information inside the repository, b) prevent some users from perceiving elements on diagrams.
At the moment:
a) I have to destroy information in the repository - I have to overwrite the LineColor Column to ensure that the arcs render in the appropriate colour. If -1 worked as per vertices, I'd just set the value to -1 and let the MDG determine the colour.
b) The current situation could/will prevent some users from perceiving arcs on diagrams - again, since you have to "jam" the column with a specific colour value. If -1 worked as per vertices, it would be relatively easy to create an MDG variant that altered the colours for various renderings (not necessarily for specific disability). We might, for example, have a "presentation" mode MDG that would allow for bolder colours, thicker lines etc. - especially for Presentation software (such as PowerPoint)
We already have toolbox variants on a per-role basis so that even though all the diagrams nominate the same toolbox, the instantiation of that toolbox depends upon the user role, so we're already handling variations from a common base.
As Simon indicates, even he expected the arcs to have the extra default layer (as I did) - but it doesn't.
So, do I have to submit a bug report or is it in hand? I accept that the repository levefl default rendering is a new feature and will submit that separately.
Paolo