Hacker News .hnnew | past | comments | ask | show | jobs | submit | varkor's commentslogin

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!


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.


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.

Thanks for your comments!


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.


There are open issues for these feature requests:

- 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!


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'm happy to see people are interested in the editor!

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...


Are there any plans to make this a desktop app. I despise graphical editors in a browser


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!


Please ignore Electron requests and consider the PWA approach.

Nice app by the way.


Diagrams.net is using electron for the desktop app, it works really well (and is fast despite what people often beieve of electron)


The problems with Electron isn't speed, rather memory bloat and multiple Chrome copies scattered around the filesystem.

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.


An electron wrapper?


It's written in javascript, you entitled twerp! The author has created this beautiful tool for free in his/her spare time.


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.


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!


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: