Changing functions from module

[ArthurMilchior]

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.

[hengiesel]

JavaScript classes can be monkey-patched, just like Python classes, using Object.defineProperty(theClass, propertyDefinition).

However, those standalone functions like setFields, and adjustFieldAmount are somewhat inacessible, that’s true.

Maybe this add-on could be reimplemented fixed without changing the TS though.

Mind the other add-ons

This is how I far I get just by playing with the CSS a little bit. This is the CSS:

.fields {
    display: grid;
    grid-gap 0.5rem;
    grid-template-areas:
        "f1 f1 f1"
        "f2 f2 f4"
        "f3 f3 f5";
}

.fields:nth-child(1) {
    grid-area: f1;
}

/* and so on:
.fields:nth-child(2) {
    grid-area: f2;
}*/

.fields > * {
    display: flex;
    flex-flow: column;
}

.field {
    flex-grow: 1;
}

The arrangement of fields could be adjusted by either providing values for grid-template-areas or grid-template-columns. More on CSS Grid.

Hopefully those pointers can help you. Honestly, if you’re up for it, I would be willing to “adopt” the add-on by writing a spritual follow-up add-on for it, maybe taking some burden off your back

[ArthurMilchior]

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

[ArthurMilchior]

Can you please confirm that you will work on this add-on ? I’m really missing it right now personally. And I’d be oh so happy not to have to look at css in details myself

[ArthurMilchior]

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.

[hengiesel]

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.

[ArthurMilchior]

Thank you very much. Really appreciate it.
I’ve been able to update multi column add-on, and get something kind of okay, but I really believe that it requires far more copy paste than ideal.

[ArthurMilchior]

Actually, it does not work
Too many things use the hard-coded fact that there is an object with id fields whose children are the fields. So anything that use a different dom structure breaks.

Ideally, if you would consider it, what I would love would be either:

• a unique ID “field_n” for the n-th field (or the field with name n)
• saving a list of fields in an array, which is not a dom array, and being able to request for the n-th field (or by name)

and that this method is used in internal code, so that it does not break when I do other things

[hengiesel]

There’s getEditorField(n), which can be used for requesting a specific field by index.

[hengiesel]

@ArthurMilchior

I’ve published my iteration on the idea here. I’d love your feedback, if you see any blatant missing features.

[ArthurMilchior]

In my opinion

f1 f1 f2
f3 f4 f5
f6 f7 f5

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.

[hengiesel]

[grid areas are] too complex

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.

From your post I take away, that you miss:

1. Extending fields with a single click.
2. Adjusting amount of columns

That seems doable.

[hengiesel]

@ArthurMilchior
I added the missing features, you can have another look if you want to

[ArthurMilchior]

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

[ArthurMilchior]

Is there a way to access fieldFocus from an add-on js? it seems it is not exported. Most values I can access them using the fields in the DOM, but writable seems far harder to get

[kleinerpirat]

I use an EventListener on editable for this:

field.editingArea.editable.addEventListener("focus", function)

---

I don’t know if editingArea and the other properties will be public on future Anki versions (pr/1403), but you could still set up these legacy props yourself:

field.editingArea = field.querySelector(".editing-area")
field.editingArea.editable = field.editingArea.firstChild.shadowRoot.querySelector("anki-editable")

@ArthurMilchior

Most values I can access them using the fields in the DOM, but writable seems far harder to get

Assuming you mean editable? It’s harder to access because it’s inside a shadow-root.

[ArthurMilchior]

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

ankitects/anki/blob/main/ts/editor/toolbar.ts#L16

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