I wish there was such a tool creating Metapost code. Metapost output is much more readable than pstricks and far, far faster than TikZ. And FWIW, it's what Knuth uses.
I remember the first time I tried to plot a vector field in MATLAB. In Mathematica, the function it is of course VectorPlot[]. I spent quite a bit of time fumbling around until I found that some funny MathWorks developer had named the equivalent function quiver() because, of course, it holds lots of arrows!
Actually it does diagrams, sequence and flowchart.
Sadly, the app has gotten more or less no development for at least 4 years and the developer has stopped responding to bug reports for at least a year. It's abandonware at this point.
Thanks for the correction! I used to use it too (I use Obsidian [1] now). Also sorry it hasn't been updated. I kind of felt that while powerful, it was also too complicated some times.
I enjoyed using Quiver (the note taking app) for a while, but switched to Windows for most of my professional work (at Microsoft). Now I just keep a folder called "Quiver" in my vscode workspace with my code snippets.
This looks like a really nice and well-made tool. Kudos and thanks for open sourcing!
One nitpick: Why do you use a Makefile without using any of the features of Make and then even requiring a special GNUMake feature to make things work like a shell script? Why not simply provide shell scripts in the first place?
* It's an old habit, I'm used to handwriting my own Makefiles for every project, and every time I start a new project it's an instinct to create a .gitignore and Makefile
* There is always a possibility of needing make features in the future. Like nowadays my makefiles have `make build` recipe which builds docker containers via docker-compose and a `make run` that depends on `build` and then shells into that container.
* make is easier to use than shell scripts since you can just do `make <cmd>` to run your command
Thanks! I use a Makefile simply because someone else contributed it early on in the development and it did the job, so I didn't see a reason to replace it. If there's a better way, I'd be happy to receive a pull request to change it!
Commutative diagrams, and pasting diagrams in particular, are a precise mathematical notation that other tools just don't handle well. I don't know many diagram editors that support edges-between-edges.
It looks very similar to tikzcd-editor. Glad people are making tools like this -- I always felt so cool putting diagrams in my homework and tikzcd-editor was what allowed me to.
I'm sure the graders appreciated it, too, since my handwriting/drawing skills are lacking.
It is a diagram whose vertices are mathematical objects and whose arrows are morphisms (often functions) between those objects such that any two paths between two vertices represent the same morphism/function. Typically it is used to infer information about one morphism or object using others, by keeping track of many properties at once in a graphical fashion.
I've been considering it. If you'd find a desktop app useful, please do open an issue on GitHub: that way I can gauge the demand a little better, which will help me to prioritise what to work on next!
It is written in JavaScript, so you will need a browser of some kind (Electron is basically a browser), unless it gets re-written in a different language.
Could you support nice-looking causal diagrams? Most look like the bubble-and-line diagrams in [Pearl 95](http://bayes.cs.ucla.edu/R218-B.pdf). I think it would increase their popularity (and the quality of science) if it was easy to include nice ones in papers & blogs.
I think you should already be able to draw most of the causal diagrams from that paper already: you can use `\circ` for the white circles and `\bullet` for the black ones. Perhaps the only missing feature is being able to draw double-ended arrows? That's on my to-do list; let me know if there's something else that's missing.
I just took a cursory look at the Javascript source and looks like it's built without any view framework or even jQuery. Is this correct?
As a backend developer curious about such frontend development, could you write up on how to architecture large apps without a reactive view framework behind. Or, if a write-up like that exists, a pointer would also be great.
This is correct: I like having full control over the application behaviour (at least down to the browser), and for a relatively small implementation like this, it's quite manageable. I make no claim this is sensible, but I've been bitten by obscure bugs in large libraries before and this way I find debugging is much easier, because I typically only have to worry about my own code.
I'm not sure I would recommend this strategy to others. It very much comes down to a personal preference, and I imagine using an existing framework would be much more accessible to someone starting frontend development. I feel I might get some stick if I were to suggest this to newcomers :) I'm afraid I don't know of any existing write-ups!
Out of curiosity: Is there a way to do commutative diagrams well with graphviz ? I'd instinctively prefer do do such diagrams in a declarative way and let a layout engine worry about making it look nice. However, I never had to dabble into area that makes heavy use of such diagrams – maybe it's just too hard to make look good for typesetting.
I also have a theory that it would be good to have a re-implementation of the graphviz core to it more modular and make extensions such as Quiver more feasible, as from an outside, layman's view graphviz is pretty old and does not necessarily work well in today's frameworks other than encapsulating it with lotsa layers above it.
A quick thing that occurs to me, adding all those elements by point and click appears to be extremely tedious, reminds me of working with music notation software and how I prefer much more something like lilypond.
This makes me wonder, is there some text serialization that could be written by hand? I picture something like graphviz notation. Quiver could use a force-directed layout as a first rough step, but users would then have to manually fix the diagram by dragging and dropping the nodes.
There's currently no direct textual input: I have considered it, but I feel it would be less efficient than the diagrammatic approach. Let me note that there is full keyboard support, which can be faster than drawing the diagrams by hand: you can see the keyboard shortcuts from the "Shortcuts" toolbar button.
1. I would like to be able to move a node by dragging it around.
2. While the "b" key does its job to move the objects, it is very confusing because it pans the view so that the moving object is fixed, giving the impression that everything moves but the object in question.
You can move vertices by clicking and dragging in the empty space around them. I appreciate this isn't immediately intuitive and I'm trying to come up with a better way to reveal this to the user.
I also agree that fixing the view to the vertices with B can be confusing. My plan is to change this.
I guess the opposite behavior would be more intuitive. If you drag the interior of the node, it moves. To add a new arrow you drag from the immediate outside of the node.
Besides, in tikz I draw 3D commutative diagrams whose arrows pass in front/behind of each other. It is rather annoying to write the code for that, and it would be nice to do that somewhat automatically. Does quiver support this? For example, to draw a 3D cube.
EDIT: more comments: there are some important missing arrowhead styles. For example, if there are bijections in your diagram, it is common to use a single bidirectional arrow with two arrohweads.
54 comments
[ 1.6 ms ] story [ 115 ms ] thread[1] https://happenapps.com
It's on my list of side projects that I never seem to put a dent into.
[1] https://obsidian.md
One nitpick: Why do you use a Makefile without using any of the features of Make and then even requiring a special GNUMake feature to make things work like a shell script? Why not simply provide shell scripts in the first place?
* It's an old habit, I'm used to handwriting my own Makefiles for every project, and every time I start a new project it's an instinct to create a .gitignore and Makefile
* There is always a possibility of needing make features in the future. Like nowadays my makefiles have `make build` recipe which builds docker containers via docker-compose and a `make run` that depends on `build` and then shells into that container.
* make is easier to use than shell scripts since you can just do `make <cmd>` to run your command
http://ipe.otfried.org/
It's by far the best diagramming tool for Latex.
I do not find it especially good for commutative diagrams, though. I usually type tikz-cd code for those cases.
I'm sure the graders appreciated it, too, since my handwriting/drawing skills are lacking.
Let me also point out that I wrote a short blog post about the motivation behind quiver, as well as some of its key features, here: https://varkor.github.io/blog/2020/11/25/announcing-quiver.h...
Nice app by the way.
The path forward are PWAs and the ability to use them in any browser.
Otherwise don't cry that Web has turned into ChromeOS, when everyone and their dog is shipping Chrome alongside their application.
Still a great job!
As a backend developer curious about such frontend development, could you write up on how to architecture large apps without a reactive view framework behind. Or, if a write-up like that exists, a pointer would also be great.
I'm not sure I would recommend this strategy to others. It very much comes down to a personal preference, and I imagine using an existing framework would be much more accessible to someone starting frontend development. I feel I might get some stick if I were to suggest this to newcomers :) I'm afraid I don't know of any existing write-ups!
Out of curiosity: Is there a way to do commutative diagrams well with graphviz ? I'd instinctively prefer do do such diagrams in a declarative way and let a layout engine worry about making it look nice. However, I never had to dabble into area that makes heavy use of such diagrams – maybe it's just too hard to make look good for typesetting.
I also have a theory that it would be good to have a re-implementation of the graphviz core to it more modular and make extensions such as Quiver more feasible, as from an outside, layman's view graphviz is pretty old and does not necessarily work well in today's frameworks other than encapsulating it with lotsa layers above it.
A quick thing that occurs to me, adding all those elements by point and click appears to be extremely tedious, reminds me of working with music notation software and how I prefer much more something like lilypond.
This makes me wonder, is there some text serialization that could be written by hand? I picture something like graphviz notation. Quiver could use a force-directed layout as a first rough step, but users would then have to manually fix the diagram by dragging and dropping the nodes.
Some UI troubles:
1. I would like to be able to move a node by dragging it around.
2. While the "b" key does its job to move the objects, it is very confusing because it pans the view so that the moving object is fixed, giving the impression that everything moves but the object in question.
I also agree that fixing the view to the vertices with B can be confusing. My plan is to change this.
Thanks for your comments!
Besides, in tikz I draw 3D commutative diagrams whose arrows pass in front/behind of each other. It is rather annoying to write the code for that, and it would be nice to do that somewhat automatically. Does quiver support this? For example, to draw a 3D cube.
EDIT: more comments: there are some important missing arrowhead styles. For example, if there are bijections in your diagram, it is common to use a single bidirectional arrow with two arrohweads.
- Crossing over arrows: https://github.com/varkor/quiver/issues/19
- Two-headed arrows: https://github.com/varkor/quiver/issues/37
I hope to get to them before too long. Thanks for the suggestions!