search

varkor / quiver

A modern commutative diagram editor for the web.
https://q.uiver.app
MIT License
2.42k stars 83 forks source link

Feature: Auto-indexing of Objects & Arrows A_1, A_2, A_3, ... #130

Closed enjoysmath closed 2 years ago

enjoysmath commented 2 years ago

There are two ways to do this. The user specifies (in another text field) what the auto-indexed expression should be, default is the most recent picked / selected Object or Arrow. Along with what part is the auto-index. Could be "..,-1,0,1,2,3,.." an integer string in base 10, or it could be a,b,c, ..., A,B,C, ..., or it could even be \alpha, \beta, \gamma, \delta, ...

Then when Auto-index is checked, and the user clicks to place something, it is automatically labeled, with current auto-index and the internal index counter is incremented (decremented).

Another way (and that could be done in addition to the above), is the user makes a selection, or no selection means do the whole diagram. The selection then gets auto-labled with the set auto-index expression say A_1, and the selected items get auto-labeled all at once. So the user could start out just drawing an unlabled graph. Then sets the auto-index expression and clicks a button. This is a user experience speed up, because they don't have to keep having to label everything as they go. Very useful for diagram chasing in homological algebra.

So this is a feature request for either of the two above features, or both of them.

varkor commented 2 years ago

This is a very specific feature that I imagine would not be frequently used, so I am not sure it is worth the implementation complexity. Considering most diagrams are relatively small, I'm not sure this needs a dedicated feature.

varkor commented 2 years ago

I think it's unlikely this feature would be worth the increased complexity, so I'm going to close this issue for now.

enjoysmath commented 2 years ago

@varkor Note, that to me it seems like you're saying each time my users want to draw a 4 x 4 grid of $M{i,j}$'s they're going to have to hand type in each one! That's not the friendliest user experience, mon. Also many of your dev users are wanting to integrate this into a math app and use quiver as a frontend editor that actually edits real math on the back-end. So I think quiver dev team should be aware that you're not creating any API's we could simply use so that when quiver updates we don't have to update our hacked local version at each change. Anyway, back to the indexing. I already figured out the best UX because the text editor was the first thing I wanted to get working in Qt/C++/KaTeX. So anyway, the way it should work is you use a symbol, say @, that we never use to indicate that 1 is an auto-index in the content: $M{i + {@1}}$, then when the user cilcks to place another node, the image needs to be rendered and ready to place, and you simply update the auto-indices. You have one auto-index plugin for arrows and another one for nodes. So the complexity in UX is 0 because you didn't add any buttons. You initiate it simply with {@<alpha, number, greek>} and you can also use {-@} if you want to decrease the aut-index.

varkor commented 2 years ago

Note, that to me it seems like you're saying each time my users want to draw a 4 x 4 grid of $M_{i,j}$'s they're going to have to hand type in each one!

So the complexity in UX is 0 because you didn't add any buttons.

Yes, I am saying this. But I don't think it's a particularly common use case – not enough to justify adding a new syntax for labels. At the moment, the label input is LaTeX – there are no special commands. Adding new syntax increases the complexity of the application and code, even if it does not add any more UI elements.

Also many of your dev users are wanting to integrate this into a math app and use quiver as a frontend editor that actually edits real math on the back-end.

I'm not aware of anyone else using quiver for this purpose. I'm afraid my priority is the user experience for people just using the app, rather than developers, because the former group makes up the majority of people using quiver.

So I think quiver dev team should be aware that you're not creating any API's we could simply use so that when quiver updates we don't have to update our hacked local version at each change.

I appreciate this might be awkward, but recently the changes have been quite minor, and I imagine it should be possible to simply rebase over the latest version of quiver without (m)any conflicts.