Support for more general purpose diagrams

[jeaye]

Intro

I think people looking to make great looking network or flow diagrams don't have many options available. Especially for free and on any OS. This has led me to mainly stick with ASCII, but its limits are so painfully obvious. After seeing Quiver on HN, I tried making one of my most recent ASCII diagrams using Quiver.

The issues

• Quiver needs a rich text editor to be able to support richer nodes (suggestion: Markdown)
• Wrapping nodes in boxes or circles will help group rich text and will aid folks in making DAGs

The example ASCII diagram

ELB (production) / Nginx Reverse Proxy (development)
+--------------------+---------------------------+----------------------------+--------------------+
                     v                           v                            v
                     v                           v                            v
                     v                           v                            v
           +---------v---------+         +-------v-------+         +----------v---------+
           |                   |         |               |         |                    |
           |   platform-link   >>>>>>>>>>>   challenge   >>>>>>>>>>>   real-time-read   |
           |                   |         |               |         |                    |
           |           keycloak|         |       keycloak|         |            keycloak|
           |              mongo|         |       postgres|         |               mongo|
           |              redis|         |          mongo|         |               redis|
           +------------------v+         |          redis|         +--------------------+
                              v          +v---------v--^-+         
                              v           v         v  ^
                              v           v         v  ^
                              v           v         v  ^
                              v           v         v  ^
                              v           v         v  ^
                            +-v-----------v+       +v--^----------+
                            |              |       |              |
                            |   geofence   |       |   schedule   |
                            |              |       |              |
                            |         mongo|       |      postgres|
                            |         redis|       |         redis|
                            +--------------+       +--------------+

The example Quiver diagram

• Available here

Summary

I realize this isn't the exact intended usage of Quiver, but it could be that your audience is larger than you had originally imagined. Thanks for the great tool and the permissive license.

[varkor]

If you wrap your text in \text{...}, that should solve the first issue. You can write \\ (outside \text{...}) to create a new line. Regarding the third issue, I'm not sure how off the top of my head how to wrap text in a box in LaTeX in a way that's supported by KaTeX, but it might be possible. I'd have to think about that one: if it's possible directly in LaTeX already, that's preferable to implementing a new feature.

[osdiab]

Not trying to bloat this project if the goal is more math than other types of diagramming as the poster requests, but it definitely adds a significant learning curve to need to learn LaTeX to apply basic formatting to the diagram. Maybe some kind of "rich text editor" style buttons to create the proper syntax could work if the project is tightly bound to LaTeX?

[varkor]

My primary motivation was to make an editor for commutative diagrams (for which I am assuming users know basic LaTeX), but if there is significant interest in making quiver more general-purpose, it's something I'm willing to consider. I'm not sure the best place to garner interest, but perhaps this issue will do for now?

[jeaye]

Definitely agreed: a rich text (maybe Markdown) editor would be superb. All of the people struggling to make nice looking DAGs with Graphviz or LibreOffice would agree, I bet. I've updated my original ticket and title to summarize this better.

[grayswandyr]

+1 for the possibility to wrap nodes (or even more: groups of cells) into boxes (circles, rectangles, etc.). Even in other areas of math or compsci, this would be most useful.

Thanks for this very interesting project. I agree with #@jeaye that, with a few of additions, your editor is of far broader applicability and use than you may imagine.

[hediet]

@jeaye have you checked out draw.io? It is FOSS and works in the browser (and even in VS Code ;) ).
I think the strength of quiver is its LaTeX support and its concentration of commutative diagrams. draw.io/diagrams.net is more like a universal purpose diagram editor - it does not look nice all the time, but is very convenient to use.

[jeaye]

@jeaye have you checked out draw.io? It is FOSS and works in the browser (and even in VS Code ;) ).
I think the strength of quiver is its LaTeX support and its concentration of commutative diagrams. draw.io/diagrams.net is more like a universal purpose diagram editor - it does not look nice all the time, but is very convenient to use.

Indeed I have. In fact, I tried it before making that last ASCII diagram. I believe the problems I had were around the fact that its node connections and labels are quite limited.

1. It's possible to connect one node to another in such a way that the arrow updates when either moves
2. However, it seems that arrow cannot have a label, unlike other arrows
3. It seems that those nodes can't contain text which is actually grouped with the node, so:
   a. Nodes need to be manually resized to contain their text
   b. All items in the node need to be manually selected before it can be moved
4. It's certainly not as screenshot-ready as Quiver

It could be that the way I'm looking to use these is not typical; that would surprise me, though.

[grayswandyr]

Regarding box typesetting, is there a way to get more control by, e.g., creating some sort of parbox/minipage (and then do arbitrary LaTeX stuff inside). I guess an issue is that an advantage of Quiver is the flexible sizing of cells, but minipages require an absolute width...

[varkor]

There's a question of how many of these advanced layout features KaTeX supports too: I don't think it supports \parbox or minipage.

[grayswandyr]

Yeah I just checked. It seems indeed there's no such thing as a minipage. I guess multiline text and alignment could partly be simulated with arrays which, apparently, are possible.

[bgoodri]

In the past, I have used

https://github.com/jluttine/tikz-bayesnet

to make DAGs with tikz, but editing them is tedious. It would be great if the quiver editor could support node decorations like that.

[varkor]

I've given this a little more thought. I think there are three aspects:

• Implementation: the motivation behind this editor is commutative diagrams. There are a reasonable number of features I have in mind for that purpose, which I want to prioritise over orthogonal features — so I would not be able to look into implementing the features you suggest any time soon. However, I do see how these could be useful to a larger community, and I know roughly how they would be implemented, so I would be happy to guide someone into implementing rich text support and vertex borders.
• Interface: I am very cautious about overcomplicating the interface, as I know that it is already quite full. At the moment, I'm not sure how to integrate these features into quiver without making it unnecessarily more complicated for the original use case. Perhaps this can be avoided with careful thought, but it is something to keep in mind.
• Future: to add these features, which are irrelevant to commutative diagrams, makes a statement about a commitment to support more general use cases. Although these two features may not be so much, there are undoubtedly many more that could also be useful for non-commutative diagrams. In practice, though there is overlap, I imagine the features and interface for a general-purpose diagram editor would look quite different to those for a commutative diagram editor. This suggests to me that it might be worthwhile to fork quiver, using the base editor, but adding general-purpose features separately from the original editor.

To summarise these thoughts: I don't think I am going to be able to commit to working on any more general purpose features that I don't see as being useful for commutative diagrams. However, if some others are interested in using quiver as a starting point for a more general editor, I would be happy to facilitate that by explaining parts of the implementation and suggesting how new features might be implemented. Unfortunately, as a side project, I only have limited time to dedicate to quiver, and so I want to prioritise commutative diagrams.

[jeaye]

Completely understood, varkor. That's your call to make. Awesome work so far and thanks for the discussion.