#14 Help with or suggestions to avoid overlapping arrows

[Martijn Schiedon]

Hi Zoltan,

I'm loving the new block language, but I'm struggling with the way arrows are drawn when there are multiple arrows between two boxes. I use this to indicate request-response patterns. Is there a way or setting that makes the arrows keep a minimum distance from each other?

Please see below example:

Kind regards,
Martijn

boxcol env1 {
    box client: Client;
    space;
    space;
    box server: Server;
    client->server>client;
}

boxcol env2 {
    box client: Client;
    space;
    space;
    box server: Server;
    # Taking control takes a lot of work
    (client@40%,client)->(server@40%,server);
    (server@60%,server)>(client@60%,client);
}

[Zoltán Turányi]

Hi Martijn,

Indeed this is an issue. I have no suggestions right now. (Well, you can omit 'server@40%' and 'server@60%', since they are the same x coordinate as 'client@40% and %60, resp.) This is yet an evolving language. Here is what I plan to add.

• ports. Each block may have ports (which is a point on the block) and you can make an arrow go there, like <block>@<port>-><block>.
• compass points. This is a direction in degrees clockwise from north, in which direction the arrow shall start, like "<block>@<port>@"
• move the calculated starting position (after all the above) by some pixels, like a+x5->b, will start 5 pixels to the right from the center of 'a'. This would be good for you: client-x10->server-x10; client+x10>server+x10;
• Make it longer/shorter by adding/substracting a number, like a+5->b, will be 5 pixels shorter on the 'a' side than just plain a->b
• Make arrows between the same two blocks automatically avoid each other. This is complicated.

All of this I have in code and tested (but not documented), except #3 and #5 (so what would be good for you). I am now hesitating to update the doc first, release - or do #3 and then release.

Comments? Both on the ideas and on timimg.

Z

[Martijn Schiedon]

Hi Zoltan,

Both options #1 and #2 sound very promising and would provide me full
control. I suppose it wouldn't always prevent lines from hiding each other,
but the chance that they do diminishes by a fair amount. #1 would be
comparable to Visio connector points, which I found a very useful feature
developing custom Visio shapes. And I noticed that sometimes the starting
direction of arrows is off, so the #2 compass points would fix that.

Regarding the timing, is it an option to release and document the first two
new features first and let any ideas for improvement of the ports and
compass points mature/materialize for a while? That would allow me to test
the ports and compass point feature, and you wouldn't have to hastily
introduce one new feature that may not be backward compatible with new
concepts you come up with.

In general, I like options that 'just work' and render stuff intelligently.
What attracts me in your software is that I can focus on the content and be
productive, and that I don't have to worry about layout and pixels so much.
So, I you would offer me the choice between option #3 and (for example) a
'use' statement with which I can globally set the (relative of absolute)
spacing between the start- or endpoints of arrows on a shape boundary, I would go for the latter
because, generally, this would generate great results. For those special
cases I would use advanced control. I hope this helps to explain my
position on the matter a bit. Of course, I realise that allowing me to
worry less about layout and pixels means that you have to worry more about
them, and I don't know if that is in line with your vision for the block
language.

Kind regards,
Martijn

edit: clarified the auto-spacing remark for begin/endpoints of arrows

[Zoltán Turányi]

Hi Martijn,

Thanks for your interest and opinion. This is pretty much how I see it too. The block language is an experiment if it is possible to create something that is overall useful (easier than visio). In general graphviz is very good and automatic, but one has very little control over how things are laid out. I have see many many questions on the internet regarding "how can I do ... in graphviz" and 90% of them is about tweaking the layout.

So I started out with a row/column based layout algorithm and here it is. Overall I think it is not automatic enough. But automating things (even the current arrow layout) is a lot of work and experimentation. But I will get there. After doing something for the overlapping arrows problem, I plan to add additional block layout methods, like circular, random or one similar to graphviz dot, where the arrows determine ordering - but with the ability to tweak. This is a bit far though.

I have added support for #3 above and packaged what I have into a 6.0.99 version. The documentation is completely off (diagrams updated, text not, etc.) In the release notes, I have summarized all the changes/additions. It is just for you - very condense, but as you see writing proper documentation will take quite some time and I did not want to wait. Please experiment and keep providing bugs and suggestions.

Zoltan

[Zoltán Turányi]

Hi Martijn,

I have now released 6.0.100 (6.1 beta 2), with a fully updated documentation and additional bugfixes over beta 1.

Next thing I will start working on is the automatic adjustment of overlapping arrows.

Zoltan

[Martijn Schiedon]

Hi Zoltan,

I gave the new features a quick test, both on the 6.0.99 and 6.0.100 release. I used the default block ports ('ne', 'left', 'bottom', etc. with the exception of 'perp') and also option 3. I'm really happy that you implemented option 3 as well, this is a really quick and easy way to adjust the start and endpoints to my liking. I'm now using both the pixel shift and relative shift (e.g. +x10%) with my diagrams.

I also defined a port on a custom shape, and while the port doesn't show up in the intellisense, it works like a charm when used as a point of departure or point of entry for an arrow.

My compliments on the solution and -as always- the excellent documentation of features!

[Zoltán Turányi]

Hi Martijn,

Thanks for your kind words, it really feels good.

I have added hinting (intellisense) for port names - but only for shapes defined and loaded as part of a design library. Is this sufficient? Or most of the time you use a shape defined in the file itself? (That would take more work for the coloring parser making it somewhat slower. Could be added if it helps a lot.)

I have released 6.1. Please, keep reporting bugs and missing features.

BTW would you volunteer to become a kind of a beta tester? If so, I would package early versions and notify you.

Zoltan

[Martijn Schiedon]

Hi Zoltan,

When I design and test a shape, which is pretty rare, I do that in the .signalling or .block file itself, so that I can quickly refresh and see changes I make. Only sometimes the shape ends up in a design library, partly because the locking of the designlib file requires closing all instances of the executable, which interrupts my 'flow'. I think the absence of specific hinting is not a problem, but maybe it's desirable from a consistency perspective; to make the behaviour and experience in the editor the same regardless of where something is defined. If performance would become an issue, I would know to put it in a designlib to let that stuff be pre-parsed.

I would sure be interested in beta testing for you. Design/visualization and documentation is part of my job, but not the whole job, so I hope it's not a problem that I can only offer you my best effort.

Thanks,
Martijn

[Zoltán Turányi]

OK, thanks. I cannot ask for more :-) I also do this as a best effort low prio thing.
I will then be sending notifications of new early builds for you sometimes.

As for the port names, I will add them.
Also, the next early beta will have some support to avoid overlapping arrows automatically, so I close this ticket.