it would be nice that many collapsed fields are presented on a single line. There is certainly enough room to put three or four names and collapse symbol on a single line, and it’ll allow the fields that I currently use to appear on screen. Obviously, the actual number of collapsed field by line would depend on the size of the window, but that’s nothing that can’t be dealt with with css.
As usual, I’d be willing to work on it if it’s accepted. It seems to require to touch the svelte part of the code, which means that it’s almost impossible to do it in add-ons (and there is a high risk the add-on breaks, as all note-editor addon do on most recent updates.)
I’d be also happy not to work on it, as I’m not a fan of CSS
After playing with it more, I’ve got a more important request. Could the set of collapsed/not collapsed field be retained in the note type? Or at least be remembered with the field name. Because the index of the field has no meaning in my usage. Which mean that each time I switch note type, which is almost every other note, I must collapse/uncollapse different fields, which make the feature almost useless.
Plus, when I reopen the “add card” window, it mean I must recollapse all fields that I’m not currently using.
it would be nice that many collapsed fields are presented on a single line.
How would you imagine this to look? I imagine that not many users use that many fields, it might also be a confusing, if the field “jumped away”.
It seems to require to touch the svelte part of the code, which means that it’s almost impossible to do it in add-ons (and there is a high risk the add-on breaks, as all note-editor addon do on most recent updates.)
It’s true that many editor add-ons broke in recent versions. There was a lot of flux with the editor, but at least for the editor fields, I think this mostly calmed down now. I’ve put quite a lot thought into making the editor extensible, even though not much is exposed currently.
Could the set of collapsed/not collapsed field be retained in the note type?
I was imagining having multiple copy of the collapsed field on the same line, one next to the other. But only if those are two successive fields collapsed; in order to ensure that the relative order of each field is always respected.
I admit that it may be strange. In particular because if you close something by accident, it may move, and you’ll have to move your mouse to re-open it.
I’m really thankful for you to make the editor extensible. Do you plan to also write a doc to explain how to do add-on to extend it, or should I just jump into the code and try to understand it.
I don’t really know Svelte. I read the introduction documentation because it’s used in Anki, and that’s it. So in particular I don’t yet know how to read Svelte code and then figure out how to write some JS add-on to interact with it. What functions and DOM elements will be accessible
If you don’t know Svelte, that’s probably a good place to start.
There’s no built-in extensibility in Svelte, so we have to built our extensibility abstractions, so we don’t want to settle on a possibly bad abstraction early on, so I’m taking this slowly.
However some of the new APIs will require Svelte and a compilation step to take advantage of them.
In this case, I’ll wait for the abstraction to settle first, as I prefer not to take too much time rewritting the same add-ons for multiple abstraction.
Unless you need feedback to decide whether you have got the right abstraction. If it would help you decide if the abstraction is the right one, I can spend some time and try to work things out and tell what where the pain point and the part I loved. (I suspect that feedback, from someone who have experience in anki, js, but not in svelte might be useful here)
