Default concept rendering behavior in diagrams not as expected [Archi 4.7]

[pschoepf]

Version of Archi

4.7

Operating System

Windows 10

Expected Behaviour

Rendering of concepts in diagrams should use preference settings unless overridden on diagram concept instance.

Actual Behaviour

After switching to ArchiMate 4.7 all our existing diagrams are rendered without gradient which is preset in preferences. Preset gradient is only used for concepts that get newly added to a diagram. If an existing diagram is opened all concepts are rendered without gradient Furthermore border line thickness is much higher than in previous archi versions (don't know if this is intented) which makes the concepts visuals less nice.

Steps to Reproduce the Behaviour

1. set default figure style to "gradient"
2. open existing diagram

Note: May be this behavior is intended and just an issue after upgrading and not for new diagrams as these will automatically use the preset from the preference but it still feels a bit weird. If I understand it currently the rendering does currently treat a missing "gradient" feature on an object as gradient = None. What about using the preference preset instead if no gradient feature has been set ?

[Phillipus]

Prior to Archi 4.7 the gradient setting was a global setting for the application. It was all or nothing. Also, it only applied to that particular app instance. This information was not stored in the model.

In Archi 4.7, this information is stored in the model per object, just like storing a fill colour or a font. The Preference specifies what gradient to use for new figures - this is the same behaviour for the "Default Figures" preferences or the Width/Height preference. (Actually, "Default Gradient" should really be in the "Defaults for new ArchiMate figures" section.)

If I understand it currently the rendering does currently treat a missing "gradient" feature on an object as gradient = None.

Correct.

What about using the preference preset instead if no gradient feature has been set ?

No, because that is not the intent of the preference (see above). Also, when sharing the model with someone else they would see a different gradient if they had a different preference.

Furthermore border line thickness is much higher than in previous archi versions (don't know if this is intented) which makes the concepts visuals less nice.

We had to set the line thickness to 1 to fix various outstanding issues related to clipping text and scaling. Previously the line thickness was not really a line thickness at all. It was the same "hairline" at all scales. Also, if we want to have other line thicknesses then the changes we have made allow for that.

See https://github.com/archimatetool/archi/issues/621 and https://github.com/archimatetool/archi/issues/637

[pschoepf]

What about using the preference preset instead if no gradient feature has been set ?

No, because that is not the intent of the preference (see above). Also, when sharing the model with someone else they would see a different gradient if they had a different preference.

Understand, I was not sure if this is the desired behavior. I guess we will get used to it although my colleague, who hates my gradient styles, will dislike all diagrams (gradient styled) created by me :-) But as you said it is consistent to the other diagram base preferences like width/height.

Any plans to provide the ability to define line thickness in the future so that we could achieve a somehow similar look for the borders as we had in the past ? Currently, it looks quite thick at least in 100% Zoom, also compared to other Tools (sure this is a matter of taste).

[Phillipus]

Any plans to provide the ability to define line thickness in the future so that we could achieve a somehow similar look for the borders as we had in the past ? Currently, it looks quite thick at least in 100% Zoom, also compared to other Tools (sure this is a matter of taste).

Unfortunately, we can't do that because of complicated reasons. I'll try to explain...

1. We had to fix various issues found when scaling a diagram at not 100% scale - clipped text and other artefacts (see #621 and #637)
2. To do this we had to stop using the Eclipse ScaledGraphics class.
3. But the side effect of that was that the "hairline" outline of each figure was no longer working on Mac and Linux (see https://github.com/archimatetool/archi/issues/637#issuecomment-645494224)

So we're now in the situation of choosing between (a) the old way which uses the "hairline" outline but has graphical bugs or (b) fixing the graphical bugs (by not using ScaledGraphics) but having to use a line thickness of "1" to work on all platforms.

[pschoepf]

Thanks for taking the time and the explanation. I had a brief look into the mentioned issues and it looks complicated ;-)

Once more sorry for hopping onto the gradient topic again but I had some discussions with my unhappy colleagues. We just tried the line colors and background feature and having the gradient behave like that would have felt more consistent. If I am not mistaken for these I can set my personal global preference and override this per diagram instance. I see that this is a different area of preference but still having lines/fillcolor and gradients behave different feels inconsistent as both are just defining the appearance of the diagram object. Furthermore working in a larger team and with people having different settings for the gradient will need some more work (or an agreement within the team so that everyone uses the same setting) to not have differently looking diagrams all over the place.

[jbsarrodie]

Furthermore working in a larger team and with people having different settings for the gradient will need some more work (or an agreement within the team so that everyone uses the same setting) to not have differently looking diagrams all over the place.

That's basically the common issue (or opportunity) in a team compared to working alone: everyone has to use the same configuration or else things will go wrong. This usually includes default colors and gradients, but also default size without forgetting the grid size which is often needed to be the same to make sure everything is well aligned.

[Phillipus]

Regarding line width, I have identified a problem. See #650

[pschoepf]

That's basically the common issue (or opportunity) in a team compared to working alone: everyone has to use the same configuration or else things will go wrong. This usually includes default colors and gradients, but also default size without forgetting the grid size which is often needed to be the same to make sure everything is well aligned.

True, the issue with the gradient is that it does not behave similar as the color preset. If I like al myl application components to look yellow I can simply set this in the preferences and it will not affect anybody else. Furthermore I can explicitly color specific instance on diagrams e.g. red- which would then apply to everybody else. But I cannot do the same with the gradient, there I will always affect the others. For me gradient and fill color kind of are in the same domain and it feels more like kind of global/theme aspect that could be overridden on a single instance but does not explicitly need to be defined there. Is there really a use case where somebody would like to have different gradients in a single diagram or across diagrams ? Apologies if that discussion gets too philosophic ;-)

[Phillipus]

If there were to be a global application preference for gradients how would it work?

It seems that, in addition to the existing drop-down in Preferences for the default gradient for new figures, there would have to be an additional drop-down for the global application default containing all the gradient settings and an additional option something to the effect of "Use gradient as set in the figure".

[jbsarrodie]

True, the issue with the gradient is that it does not behave similar as the color preset. If I like al myl application components to look yellow I can simply set this in the preferences and it will not affect anybody else.

Well, in fact that's only because of some legacy feature in Archi: some years ago there was no support for custom default colors. When this was added, we were unsure of what should be the right behavior: use default color and make it persistent or don't set color and make it dynamic. At that time I was modelling on my own and didn't had experience and feedback to make a choice, so we decided that, by default, default color won't be stored and thus dynamic, but we also added an option to make them persistent. 7 years later, I can tell you that the right choice is to store default color to make sure that everybody you share your model with see it exactly as you decided it to be. I've seen plenty of issues with people I work with (colleagues and clients) simply because they didn't enable storing default color.

Phil and I will have to discuss it of course, but I'd advocate to remove this "dynamic" default color behavior, and maybe even remove it completely because it causes much more trouble than it solves.

So I really do think that current behavior for gradient is the right one.

In fact, the only other solution I can see would be to not rely on user defined defaults, but instead have per model default. This would allow for quick and global changes, but would make sure than everyone see the same thing when opening a model.

[Phillipus]

In fact, the only other solution I can see would be to not rely on user defined defaults, but instead have per model default. This would allow for quick and global changes, but would make sure than everyone see the same thing when opening a model.

I think that is the right goal. For example, orthogonal anchors setting should be stored in the model.

I think application specific settings should only affect the app not the app's data. We should aim to ensure that everything is contained in the model so everybody sees the same thing.

Another example, "derive element line colours from fill colours" should not be an app preference. It should be per model, and/or per figure.

[jbsarrodie]

I think that is the right goal.

Yes. "app" level default should not impact the way the model in rendered, only how Archi behaves (like putting unused element in italic in the model tree).

Of course we might have "app" level default which defines the default "model" level defaults: they are copied when creating a new model, but no more impact it after.

[pschoepf]

7 years later, I can tell you that the right choice is to store default color to make sure that everybody you share your model with see it exactly as you decided it to be. I've seen plenty of issues with people I work with (colleagues and clients) simply because they didn't enable storing default color.

I see your point, that way a diagram would be like a stable "picture" which always looks the same as the "artist" original had drawn it. On the other hand it is also nice to be able to switch e.g. from layered-based color coding to type (behaviour, structure..) based color coding without the need to touch diagrams which is easily possible as of now. And I still can hardly think about a use case where I would need to use different gradients in a single diagram because it would most likely look odd.

I think application specific settings should only affect the app not the app's data. We should aim to ensure that everything is contained in the model so everybody sees the same thing.

+1 Having the possibility to steer that on model level would be ideal. That way I could share it the way I wanted it to look but it would be just a small bunch of clicks to change it to another style/color theme. I guess that's a larger rework but you'd have my vote for it;-)