First, thanks a lot @hengiesel for your contribution to the typescript code. It’s a real pleasure as an add-on developer to see code which is easier to understand.
Sadly, it makes porting some of my add-ons to latest anki version far more difficult than I expected, (And @AnKingMed keeps reminding me that some people care about them ).
Is there any way to modify a function inside a ts module ? I used to do a lot of monkey patching, and I can’t figure out whether it’s even possible anymore. In editor/index.ts I’d love to change adjustFieldAmount, so that instead of having all fields one below the other, I could have multiple columns, as I used to in Multi-column note editor - AnkiWeb
If there is nothing that can be done, would it be possible to consider a TS hook system, similar to what is done in Python?
What I fear is that if I just use the current add-on (which mostly work, except for some css issues, by redefining setFields) it will be incompatible with other add-ons changing the editor.
You’re more than welcome to take over whatever add-ons trigger your interest. I care about the fact that add-ons and feature work, not about who do the job. In this case in particular, I used this add-on every day and find it really complex to create notes without it, so if you do anything to correct that would be wonderful.
If you do a PR, I’ll gladly accept it and upload it. If you prefer, i would also be fine giving you right over this add-on. Which I’ll actually find fun since it’s the only add-on I didn’t originally create but that was given to me by the original author so that they don’t have to publish my PR themselves.
Same things is true with any other add-on you see that is out of date and I didn’t correct. In particular anything that touch the reviewer, since it changed so much and you know the new code, it’ll probably be easier for you.
Resize image seems to be the most important one, and also my port of Frozen Field Frozen-field compatible with other add-on - AnkiWeb that was changed to be compatible with other add-ons modifying the editor
do you think it would make sens to put all methods of modules in exported classes ? This way it can be easily monkeypatched the same way Anki used to be. Not as good as hooks, but it would do the work.
If you give me a few more days, I’ll certainly implement this. I assume that it won’t take me longer than a day or two.
You monkey patch the class even without the classes being exported, you can use var cls = Object.getPrototypeOf(obj); cls.prototype.method = myMethod;. Imho monkey patching is a very vulnerable way of extending functionality because of the high coupling, so it should be regarded as a hack in any case.
is too complex. Obviously for people who prefer GUI. But even for me, it would be really easy to forget a number, to have to take time thinking about what exactly I want to organize the window
I admit, because it’s obvious, that your design is more versatile than HSSM’s design (I’m not the original author by the way). However, it’s really really nice to be able to extend a field in a single click when exceptionnally I need to put big content in it, and then to make it small again so that I can use it with its usual small content. Needing to change text would make me loose more time than I would win.
Furthermore, sometime the window is small on top of content I want to ankify, in this case I’ll have 2 columns, rarely three. When it takes a half-window, I may use four columns. Being able to move from one to other setting in a single click is really helpful.
That’s a lot of small things but I clearly would miss it if I didn’t have it.
It basically just elevates this CSS feature. I agree it’s a bit more complicated, but turning this into a Qt GUI would take much much much more effort. That’s why I also added the Auto columns feature.
Just updated anki. My multi-column broke again. So I give a try to your add-on.
There was already a bug report mentioning new fields. More troubling for me is that when you change the note type, there is a single column once again. I change the note type almost every single note, which make it hard to use.
I’m not even sure whether the number of columns is supposed to be saved in the note type, in the whole app or just in the open window, due to how it interacts with changes here. Personally, I need it to have it saved in the note type, as the important fields which may get a lot of content are quite distinct from note to note.
Another trouble is that if field 4, called “definition” takes a full row, let’s say, and I add a field at position number 2, I still would want “definition” to take full row, even if it became field 5. So using the field ord instead of its name is not practical.
(to be more specific, it is practical to write the scheme, as it ensures that the scheme is short. But once the scheme is saved, I believe name should be kept as parameters and not position)
One thing that would help would simply be to allow to start with a prefilled scheme. Let’s say if you selected to have 4 columns, then you prefill with
ffield1 ffield2 ffield3 ffield4
ffield5 ffield6 …
So that you don’t have to type the fields, you can just move them, and if you want only one or two fields to be bigger than the other one, you can just change those two fields while keeping everything else alike as in prefilling.
I do love the number of option your add-on provide. But I still fear that for note types with dozens of fields, this require too much work. Even if it can be solved with few extra features
Hi Kleinerpirat. Thanks fo the help. I understand how my question might be not precise enough, please let me try to clarify it.
When I mentionned fieldFocus I didn’t mean that I wanted to do something when the focus is set on the field. What I wanted is to be able to change the value of the writable constant fieldFocused, defined at
And now I realize I forgot two letters ending the variable name, my bad
The reason I want to do so is that I was redefining forEditorField and also redefining every method using forEditorField. in particular I want setFields to use my implementation of forEditorField. However, in order to change nothing else, I need to be able to access fieldFocused