Seeking a graphviz like, diagramming language for Racket

[Andrew Gwozdziewycz]

Hi folks,

I've been using graphviz for years for basic network architecture
diagrams and things, mostly to avoid answering the question of "which
annoying tool should I use?" Graphviz has limitations for the type of
stuff I use it for, but I settle for it anyway, since it's a lot less
frustrating to use a language for laying out relationships than
clicking and dragging lines connecting things, in an agreed upon
diagramming tool.

Has anyone started work (or finished work, or even somewhere in
between?) on a diagramming language that might be, or even eventually
will be a suitable replacement for performing these types of tasks?

And if not, does anyone have suggestions for getting started with
layout drawing algorithms suitable for such a thing? I'm fairly sure
that the pict language will do the heavy lifting work for actually
drawing on a canvas, and simple layout techniques probably would go
along way, but getting to know the field a bit might be useful...

Cheers,

Andrew
--
http://www.apgwoz.com

[WarGrey Gyoudmon Ju]

I have been working on it, but at very beginning stage and no working code right now.

The official website of Graphviz  provides lots of papers on the underlying algorithms,

I also found Handbook of Graph Drawing and Visualization is worth reading.

--
http://www.apgwoz.com

--
You received this message because you are subscribed to the Google Groups "Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[David Storrs]

It sounds like an interesting and useful project.  What would you want this solution to do, exactly? 

--
http://www.apgwoz.com

[Jens Axel Søgaard]

Maybe you can find something useful in MetaPict?

    http://soegaard.github.io/docs/metapict/metapict.html

As for algorithms, this module contains references to interesting tree drawing algorithms:

    https://github.com/soegaard/metapict/blob/master/metapict/tree.rkt


/Jens Axel

[Andrew Gwozdziewycz]

On Sat, Aug 19, 2017 at 6:21 AM, WarGrey Gyoudmon Ju
<juzhe...@gmail.com> wrote:
> I have been working on it, but at very beginning stage and no working code
> right now.

Are you focused more on replacing Graphviz, or a generalized drawing
and visualization library that could be used to more easily put
together a Graphviz like tool? I guess they are likely somewhat
similar goals...

> The official website of Graphviz provides lots of papers on the underlying
> algorithms,
> I also found Handbook of Graph Drawing and Visualization is worth reading.

The Handbook of Graph Drawing and Visualization looks really great!
Thanks for the recommendation!

>> email to racket-users...@googlegroups.com.

>> For more options, visit https://groups.google.com/d/optout.
>
>

--
http://www.apgwoz.com

[Andrew Gwozdziewycz]

On Sat, Aug 19, 2017 at 7:10 AM, David Storrs <david....@gmail.com> wrote:
> It sounds like an interesting and useful project. What would you want this
> solution to do, exactly?

The last public hack job I did using graphviz is something like this:

https://heroku-blog-files.s3.amazonaws.com/posts/1488278436-new-architecture.png

As you can see, it gets the point across, but it's not ideal from a
visualization stand point. From a creation standpoint it's great! You
basically declare the relationships, and a drawing comes out.

https://gist.github.com/apg/8c3c8b0bed910faa272aa9e8d6b4f718

My goal is probably somewhere in between in terms of layout. I want a
bit more flexibility, but a decent amount of help with layout. And, I
want a lot more flexibility, and a nice set of primitives for the
actual nodes themselves.

Jens' metapict, and pict itself probably provide enough to take a
serious stab at recreating that diagram more manually, and seeing
where it falls flat, so I'll try that as an exercise next week and
report back.

>> email to racket-users...@googlegroups.com.

>> For more options, visit https://groups.google.com/d/optout.
>
>

--
http://www.apgwoz.com

[Andrew Gwozdziewycz]

On Sat, Aug 19, 2017 at 7:19 AM, Jens Axel Søgaard
<jens...@soegaard.net> wrote:
> 2017-08-18 12:10 GMT+02:00 Andrew Gwozdziewycz <apg...@gmail.com>:
>>
>> Hi folks,
>>
>> I've been using graphviz for years for basic network architecture
>> diagrams and things, mostly to avoid answering the question of "which
>> annoying tool should I use?" Graphviz has limitations for the type of
>> stuff I use it for, but I settle for it anyway, since it's a lot less
>> frustrating to use a language for laying out relationships than
>> clicking and dragging lines connecting things, in an agreed upon
>> diagramming tool.
>>
>> Has anyone started work (or finished work, or even somewhere in
>> between?) on a diagramming language that might be, or even eventually
>> will be a suitable replacement for performing these types of tasks?
>>
>> And if not, does anyone have suggestions for getting started with
>> layout drawing algorithms suitable for such a thing? I'm fairly sure
>> that the pict language will do the heavy lifting work for actually
>> drawing on a canvas, and simple layout techniques probably would go
>> along way, but getting to know the field a bit might be useful...
>
>
> Maybe you can find something useful in MetaPict?
>
> http://soegaard.github.io/docs/metapict/metapict.html

I think there's definitely a lot of interesting pieces to MetaPict
that will help! And, if it doesn't help directly with these efforts,
it'll at least be fun to play with!

>
> As for algorithms, this module contains references to interesting tree
> drawing algorithms:
>
> https://github.com/soegaard/metapict/blob/master/metapict/tree.rkt

Great!

Thanks!


--
http://www.apgwoz.com

[Daniel Prager]

Hi Andrew

I did commercial work on mind-map like tools in the 2000's, and have a soft spot for graph and tree visualisation. 

Example: https://www.researchgate.net/figure/221249211_fig1_Fig-1-Example-hi-tree-laid-out-in-the-standard-layout-style-It-shows-the-logical

I didn't work on the deep layout algorithms, but have some handy peripheral knowledge.There's a tension between the manual effort of the interactive tools and more automated layout algorithms. In my ideal world the auto-layout does most of the heavy lifting, but the layout doesn't jump around too much in interactive work, and the user can easily play with styles, aesthetic criteria, and nudge the layout to some extent. It's not easy to get all at once!

In practice, I tend to settle for GraphViz for my occasional graph-diagramming needs, but would welcome a Rackety competitor. My sense is that it may be feasible to do better for specific needs, and challenging to beat GraphViz as a general purpose tool.

Here's a nice introduction to the evolution of tree-layout algorithms, explaining how aesthetic criteria were gradually captured in a series of principles for layout algorithms to satisfy:

Principle 1: The edges of the tree should not cross each other.

Principle 2: All nodes at the same depth should be drawn on the same horizontal line. This helps make clear the structure of the tree.

Principle 3: Trees should be drawn as narrowly as possible.

Principle 4: A parent should be centered over its children.

Principle 5: A subtree should be drawn the same no matter where in the tree it lies.

Principle 6: The child nodes of a parent node should be evenly spaced.

The author of the first reference, Kim Marriott, is an active academic in the area of constraint-based graph and tree layout. I collaborated with him and his student Peter Sbarski on the above-mentioned commercial work. Kim's a good source.

Dan

[Robby Findler]

There are a few tree layout algorithms implemented in
pict/tree-layout: http://docs.racket-lang.org/pict/Tree_Layout.html

Robby

[WarGrey Gyoudmon Ju]

On Sun, Aug 20, 2017 at 1:20 AM, Andrew Gwozdziewycz <apg...@gmail.com> wrote:

Are you focused more on replacing Graphviz, or a generalized drawing
and visualization library that could be used to more easily put
together a Graphviz like tool? I guess they are likely somewhat
similar goals...

Firstly, I just write it for fun, but also focus on high quality real world applications

since I do not want to use any software design tools that force me dragging and clicking.

In untyped racket (but may not in the main distribution), there are a lot of small packages

that focus on one or more subfields of graph visualization and layout algorithms. In typed

racket, there also are pict3d, plot, and flomap based images. So I think they definitely benefit

user-designers and covers lots of everyday usage, but user-developers may need more

extension abilities since modern applications grow too fast.

Therefore, I am writing a modern design engine for programmers with an elegant functional interface,

graphviz like tool is one of the applications of this engine, actually it is likely to be the first one.

For now,

* CSS syntax and its computation model is chosen to style elements and items;

* New architecture and datatypes is coming soon for reading/composing/writing image resources.

Also I am glad to write the entire tex system in native Typed Racket, though it is really a huge

project and therefore a long term plan.

 

[Andrew Gwozdziewycz]

As promised, I mocked up my original vs a quick iteration using pict.
It's not nearly as time consuming as I thought it'd be (took about 30
minutes not being familiar with the pict api):

https://gist.github.com/apg/e193b3f4b1626397ebb3065947a6ae8a

It's obviously not visually the same, but the same information is
basically conveyed in both. My biggest complaints are that of where
arrows end up, but other than that, This isn't tooo horrible as is,
but could be oodles better with some helpers.

Cheers,

Andrew

--
http://www.apgwoz.com

[Sam Tobin-Hochstadt]

You might be interested in some of the line-drawing/edge-finding code
here: https://github.com/samth/edinburgh-2017/blob/edinburgh-2017/lib.rkt#L144

Sam

[dbohdan]

Mermaid (https://github.com/knsv/mermaid) is a useful alternative to GraphViz for the cases in which it specializes.

If you're working on your own diagramming DSL, you may want to look at these for inspiration:

* Diagrams for Haskell (https://archives.haskell.org/projects.haskell.org/diagrams/);
* CL-DOT for Common Lisp (http://foldr.org/%7Emichaelw/projects/cl-dot/).

CL-DOT generates DOT files. Its graph examples are impressively concise. It's under 500 SLOC, but seems to heavily use CLOS, so a Racket translation wouldn't be quite straightforward.

[Andrew Gwozdziewycz]

For those of you whom I still have the attention of, I recently found this:

http://blockdiag.com/en/blockdiag/index.html

This is almost exactly what I was looking for (except that it's
written in Python), but the idea is the same.

> --
> You received this message because you are subscribed to the Google Groups "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to racket-users...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

--
http://www.apgwoz.com

[John Greco]

For whatever it's worth, the racket package 'graph' can output to graphviz.  I'd be excited to see graphviz superseded by a superior diagram DSL though.

[Jens Axel Søgaard]

Updated MetaPict today in order to fix missing exports from node.rkt.

The following example now produces this picture:

    https://imgur.com/a/AYTz7

The parameters to control the shape of the arrow is explained here:

    http://www.ntg.nl/maps/36/19.pdf

but the default arrow looks fine.

#lang racket

(require metapict)

(set-curve-pict-size 400 400)           ; pict size

(curve-pict-window (window -1 3 -1 3))  ; x in [-1;3] and y in [-1;3]

; ah means "arrow head"

(ahangle         45)       ; default head angle 45 degrees

(ahflankangle    0)        ; default "curvature" of flank (in degrees)

(ahtailcurvature 0)        ; default "curvature" of the back  todo!

(ahratio         1)

(ahlength        (px 6))

; node centers

(define c1 (pt 0 0))

(define c2 (pt 2 0))

(define c3 (pt 0 2))

(define c4 (pt 2 2))

; nodes

(define n1 (circle-node c1 .3))

(define n2 (circle-node c2 .3))

(define n3 (square-node c3 .3))

(define n4 (circle-node c4 .3))

(define (outside n1 v s)

  (define a (anchor n1 v))

  (define n (normal n1 v))

  (pt+ a (vec* s n)))

(define (besides p dir s)

  ; point next to p in the direction dir,

  ; the parameter s determines how far 

  (pt+ p (vec* s dir)))

(define (between p1 p2)

  (med 1/2 c1 p2)) ; midpoint

(margin 5

        (draw n1 n2 n3 (filled-node n4)                ; the nodes

              (label-bot "AB"  (outside n1 down 0.05)) ; label below node n1

              (label-cnt "42" c1)                      ; contents (42) in the center of node 1

              (draw-edge n1 n2)                        ; edge from node n1 to node n2

              (draw-edge n1 n3 west south)             ; edge from west side of n1 to south side of n3

              (draw-edge n1 n4)                        ; edge from node n1 to node n4

              ;                                        ; label right of midpoint of nodes 1 and 4

              (label-rt "transition"

                        (besides (between c1 c4) east 0.1))))

--

--
Jens Axel Søgaard