Closed rojoweko closed 2 years ago
The old Interface figure was just a circle, and an oval shape when the figure was resized to a rectangle. That was a legacy thing on my part which was just wrong. The new Interface figure matches that in the 3.1 spec:
https://pubs.opengroup.org/architecture/archimate31-doc/apdxa.html#_Toc10045477
I'm not going to change it back, or have a special case of 3 possible figures. However, we plan to provide a set of alternate shapes for all concepts so this will be possible then.
@Phillipus in fact I agree that the old one was better. I should have told you before but was focused on specialization and forgot to come back to new figures.
Re interface, the alternative notation is not an icon but only a ball. The connection is a tricky part because it is not part of the interface but an alternative notation for the composition (which then looks like an association). So the previous alternate figure (ball) was the best compromise until we also tune composition for this special case.
I might also have some adjustments or remarks on other figure. We should sort this out quickly so for 4.9.1.
I'll have a look this week-end.
Thanks for dealing with this! ;-)
@jbsarrodie: Opinion regarding the tuning of the composition relationship: To my mind a modification of the composition relation in combination with an interface is not favourable for the following reasons:
@jbsarrodie: Opinion regarding the tuning of the composition relationship: To my mind a modification of the composition relation in combination with an interface is not favourable for the following reasons:
I understand your points, but ArchiMate specification made this clear until 2.1:
A business interface may be part of a business role through a composition relationship, which is not shown in the standard notation[...] (see here) An application interface may be part of an application component through composition (not shown in the standard notation)[...] (see here
In both excepts, "standard notation" refers to icon notation (which was borrowed from UML)
@Phillipus here is my global feedback on new icon figures and some enhancements proposal. I can certainly manage to code them quickly, but before doing so I'd like us to agree.
We have two types of icons:
Issues:
If we focus on the "Icon behavior":
To fix these two issues, I would suggest two possible behavior:
Min(figure.width, figure.height)
.Min(figure.width, figure.height)
.Min(figure.width/2, figure.height)
. This ensure the icon is always visible but not too wide so that the text is a bit wider.Now, re "Interface": The issue I see is that some people already use the alternate figure, so we should try to limit the impact for those users. And as said, there's a misunderstanding on what the real icon is (because for Interface, Networks and Path, the specification in fact describes an alternative notation embedding the relationships, and not a real icon notation). So I think a good compromise would be to not draw the small line in the icon and keep only the ball:
@Phillipus here is my global feedback on new icon figures and some enhancements proposal. I can certainly manage to code them quickly, but before doing so I'd like us to agree.
After having spent months of my life tweaking these figure and making them look half decent, plus the nightmare of last year working around line thickness and other issues, I really don't care any more.
I've just added a new icon-figures
branch containing adjustments for my previous suggestions.
- If text is on top or bottom (i.e. icon is pushed to the far bottom or top), make the icon the size of
Min(figure.width/2, figure.height)
. This ensure the icon is always visible but not too wide so that the text is a bit wider.
After some experiment I don't find it nice or useful to use figure.width/2
, simply using figure.width
(or figure.height
if smaller) seems better.
Here's an example of what icon figures looked like before for each cases (all text position, portrait and landscape):
And how it looks now:
Icon size is no more influenced by text size, and resizing the figure is enough to have the text outside the drawn icon.
Here's what Interface looks like with my proposed patch:
And how it (IMHO) solves original issue while still be better than what we had in 4.8:
@jbsarrodie Yes, I get what you've done there and this certainly provides more options for the user.
The Collaboration, Interaction, Gap, Material, and Course of Action figures are smaller, though.
Compare before and after (text is middle, centred):
Before:
After:
There is an AbstractTextControlContainerFigure#getTextControlMarginHeight()
method which some of the iconic figures over-ride and return a value of 0 in order to give more space for the figure when the text is at the top or bottom. But with this new way of drawing figures this is no longer needed and if we don't over-ride it, it keeps the margin consistent between alternate and main figures.
The Collaboration, Interaction, Gap, Material, and Course of Action figures are smaller, though.
Yes, this is because in my code I tried to limit changes so that we can discuss them if needed.
I can easily fix this by changing the signature of AbstractTextControlContainerFigure#setFigurePositionFromTextPosition(rect)
method so that it takes another argument iconRatio
(could be optional and in that case 1
would be used). This will make it possible for the figure to make sure the returned rect
better fits the icon.
That being said, I have the feeling that some icon are a bit unbalanced anyway and I might also adress this.
@jbsarrodie Do what you think is necessary. The aim is to make the figures as good looking as possible.
BTW - the idea of having text above and below the icon figures came from Nicolas Figay:
(rect.width / 2) - (diameter / 4)
becomes
(rect.width - diameter) / 2
See, I knew there was a real mathematician around here somewhere. 😉
@jbsarrodie Did you get any further with tweaking the figures? Shall I release 4.9.1 with existing changes or wait a little longer?
I had to switch to another topic but will finalize today. So please wait a bit more.
I had to switch to another topic but will finalize today. So please wait a bit more.
Now done. Can you please see what it looks like with your test model (mine seems fine) ?
BTW, I also fixed a regression to be sure that custom image (if any) would fit the whole figure instead of only the icon portion.
Thanks for that.
BTW, I also fixed a regression to be sure that custom image (if any) would fit the whole figure instead of only the icon portion.
I'm not sure if this affects SVG export to image.
Rectangle imageBounds = rect.getCopy();
// Set line width here so that the whole figure is constrained, otherwise SVG graphics will have overspill
setLineWidth(graphics, 1, rect);
Here. rect
is changed by setLineWidth
so imageBounds
won't have the offset that setLineWidth
adds. Not sure if this affects SVG or anything else? I can't see any difference. but just point this out...
Not sure if this affects SVG or anything else?
Not sure too. And if it does affect SVG, that should be only with custom images. So I suggest to keep it like that, publish 4.9.1 and wait for more feedback from users.
I'm happy to do that. I'll release 4.9.1 tomorrow. Any tweaks can be done in 4.9.2 if necessary.
I'll merge your branch if OK with you.
I'll merge your branch if OK with you.
Ok ;-)
Just a note for the record...
When I was tweaking the figures the use cases to test the figures are:
With:
Test:
I found that it's hard to get the right balance. What might look OK in one case might be off by 1 pixel in another.
Having said that we do a bloody good job of it compared to Mod..., er, another Eclipse based modelling tool... ;-)
- Line thickness set to 1, 2, 3 (currently not implemented but could be one day)
I have plenty of use cases for this, but we should also revisit border color at the same time though (be able to set 'auto' darker color or 'custom' color on a per visual object basis).
- Line thickness set to 1, 2, 3 (currently not implemented but could be one day)
I have plenty of use cases for this, but we should also revisit border color at the same time though (be able to set 'auto' darker color or 'custom' color on a per visual object basis).
I don't think that would be too difficult. I'll take a look at that.
Archi 4.9.1 is available with these changes.
Thank you very much for the changes regarding the icon representation of ArchiMate elements in the new release! That makes the diagrams look much nicer! ;-)
Just one other question regarding this topic:
Is it possible to have the connections terminate at the visible (inner, not necessarily rectangular) boundary of the icon instead of the invisible (outer) boundary with the resizing handles? The termination at the invisible boundary potentially leads to a visual gap between the end of the connection and the element symbol, which is a little bit unfortunate (especially with the non-square default size boundaries of the icons, that cause a quite large gap when connections terminate on the left or right side of the icon). This seems to apply to all icon representations as well as many other non-rectangular shapes.
Is it possible to have the connections terminate at the visible (inner, not necessarily rectangular) boundary of the icon instead of the invisible (outer) boundary with the resizing handles?
Because of the way connections work, that's not possible.
But with the new icon figures, you can change the icon position by changing the text position (if text is on the right, icon will be on the left and so on). And because icons will (almost) always touch the border, this means that you should be able to find an icon position that makes it appear connected without any gap.
That's how I did this (elements are selected to visualise their "bounding box"):
OK, thanks for the quick response! ;-)
Hi,
please consider readding support for the former alternative Archi interface representation, because they offered an elegant and scalable way of visualizing interfaces in diagrams. The round, colored shape made them identifiable as interfaces at an instant and a (usually) directly to the shape connected composition relationship practically provided the line segment for the alternative interface notation specified in the ArchiMate standard. Therefore I used this notation in most of my diagrams. They potentially have to be readjusted to look proper again with the new representation.
Would it for instance be an option to add the oldstyle representation as an additional alternative shape or to introduce a preference setting that substitutes the old alternative shape for the new one?
Thanks in advance! ;-)