Tell users to restart after (un-)installing and toggling enable/disable add-ons

Anki’s behavior - that you need to restart for these changes to take effect - should run counter to the average user’s expectation. Add-ons or extensions are best known from browsers and in these enabling/disabling or installing/uninstalling hasn’t required a restart in years. So I think Anki should inform the user, e.g. show a tooltip or maybe even a dialog (like showText)? On ankiweb I sometimes see negative reviews for add-ons that obviously change the gui that read like “no effect at all”. Then I wonder if these people restarted …

Another idea: If you restart Anki for the first time after installing an anki update anki should directly query for add-on updates (to get add-on versions for the new anki version). When just relying on auto-updates it can take up to 24 hours until users get informed that add-on updates are available for their new anki versions. In this time they might have seen many error messages and concluded that updating anki is too risky. Maybe the profile could store something like “last run was from anki version”?

I thought it would be less annoying if it was shown at the top left of the add-ons screen, but if people are not reading it, maybe we should use pop-ups instead.

Doing updates on startup and keeping track of the last run version sounds reasonable. Something to consider is whether add-ons should be loaded on that first run. If their running was deferred until after the update check, it may not be safe to load them later than they’d normally be loaded, so loading them may need to wait until the next restart.

I must admit that I forgot about this line. I’m sure I read it at some point but I didn’t think of it before posting.

About updates after a new install: I just wanted to suggest that anki does an update check and presents updates with the existing gui. So that instead of the usual 24hours an extra update check comes after the first start of a new anki version. This seemed like a quick fix that didn’t require much code or testing. I’ll spare you a pull request - when I suggested to include add-on info in the debug info about two years ago I think you spent more time fixing my pull request than it would have cost you doing it alone in the first place …

Maybe the best solution would simply not to require restart in order to enable / disable / update add-ons. I have to admit that I don’t understand why it’s not already the case, since with Python it’s quite easy to load code on-the-fly.

1 Like

@BlackBeans: I know that my use case is very rare. But I actually like to examine the new add-on code that is downloaded before it’s executed after a restart. So I do like the Anki behavior and - though I’m not a developer - I can imagine that you avoid all kinds of rare, weird problems if you avoid reloading code on-the-fly. Even though they might be rare tracking them down might cost a lot of addon developer time and bring quite a few downvotes which most add-on creators really dislike. At least writing an add-on that reliably reloads add-ons seems to be difficult, see Addon Reloader (for addon developers) - AnkiWeb and getting the 1000 existing (or 100 top addons) updated to some new reloading structure would probably take a long time (see e.g. the discussion about 2.1.50 and version numbering).

1 Like

This is a sane habit, but it doesn’t actually rely on the fact that Anki cannot reload add-ons on the fly, since you could just go and read the source code of the add-on in its repo. If that’s too much of a hassle, I could see some feature of Anki that offers you to check what you are downloading before installing it, when adding a add-on (maybe a button that opens the source code?)

Well, it’s clear that the less features you offer, the less problems arise, but with this logic no features would ever be implemented.

Normally, it would only be up to Anki to make it so that add-ons can be reloaded. Add-ons developer shouldn’t even see the difference. In practice, that might end up in a small API change at most, I don’t think that’s were the problem lies. I think the hard part is more from the Anki point of view, because that means having a more robust add-on management system. However, I believe it should not be impossible, as I have already written generic add-on managers in python, and it’s relatively small and simple.

Installing and updating already show modal dialogs that inform about the required restart. I’m sure there are people who don’t read that message and rather leave a negative review, but there’s nothing Anki or the add-on author can do about it.

As for toggling enabled, would that really be an improvement then? If you enable an add-on, it will at least have been enabled after its download, so the user will have been warned about restarting and seen the add-on work.
I think the embedded message should suffice in that case, because modal warning dialogs can get quite annoying.

Regarding some points off topic:

Not all add-ons have public repos.

I can think of a few reasons:

  • It’s impossible for Anki to know which parts of the program an add-on affects, so it would need to reload everything (refresh GUI, rebuild card queues, rebuild webviews, …), which is error-prone, wasteful and may inconvenience the user.
  • Many add-ons rely on being executed at a certain stage of the setup process and may fail to work if some step, which they interfere with, has already been finished.
  • A routine could be altered while it’s running, leading to all sorts of failures. In the most extreme case, what if an add-on monkey-patches the reloading routine?

Also, (while apples and oranges) executing code from the internet at runtime makes me think of Log4Shell…


Yes, I can see your points, however

But all add-ons have to provide code to Anki, which could, in order, show it to the end-user.

This heavily depends on what kind of add-on integration architecture you use. If you have a dispatcher / callback kind of integration, it’s quite easy to see where add-ons have impacts.
For instance, this is also how most framework-like gui toolkits work with widgets (where widgets somehow act like add-ons for the toolkit).
As for the reload-everything, I don’t think that reloading “everything” might be more wasteful or provide inconvenience for the user than restarting.

Yes, that’s indeed a non-trivial issue.

Well, I see two problems here:

  1. What if I disable an add-on while it is doing something? Can it lead to an undefined state?
    The answer is no, as long as add-ons are not allowed to run in parallel. Of course, an add-on could always start threads on their own, but you can’t prevent add-ons from screwing themselves up, can you? And it can be made them not running in parallel with, again, the simple dispatch / callback model. But other models might not enforce this.
  2. What if add-ons monkey-patch the reloading routine?
    I don’t have an answer to that. I don’t know whether monkey-patching the reloading routine should be allowed for add-ons, but this doesn’t strike me as very problematic.

Yes, well, it’s clear that add-ons could be malicious…

That would be nice, but require a lot of development time, so a dream for the future.

Well, we’re talking about Anki, where add-ons can change any piece of Python code.

When restarting, the user knows what to expect (e.g. losing their undo history), and appreciate the required resources as they coincide with their own (time).

It’s unclear to me what you mean by running. The only thing an add-on might do is overwrite an existing function. Then if you disable it, even if you could restore the original function, it may not work as intended, as it has wrong assumptions about previous calls to itself.

You’re right my text was not very precise.

My first suggestion is indeed not about installing or updating. It’s actually just about uninstalling and enabling/disabling. For this a modal dialog was not my primary idea but just showing a tooltip “Please restart Anki to apply changes” after uninstalling an add-on or enabling/disabling an add-on. This is about a clear visual reminder about what people probably read at some point in the past.
I have answered a few hundred support threads over the years on reddit about Anki and my impression is that many people miss text in dialogs or quickly forget about stuff that the software showed them. Experienced users who constantly toggle enable/disable should quickly learn to ignore this tooltip. So they’re workflow won’t be slowed down.



The second suggestion is about anki updates. take the following case:

  • E.g. I have Anki 2.1.40 and 10 popular add-ons that work well on 2.1.40
  • My Anki checks at 17:00 for updates. So according to this code the next add-on update check will be tomorrow at 17:00h
  • At 18:00 I close Anki. I download 2.1.49, install it and restart Anki. Due to the changes in Anki between .40 and .49 probably between 2 and 4 old installed add-on versions will be broken. If the user had the most recent add-on versions they probably wouldn’t get an error. Anki will only show about these add-on updates - in my case - about 23 hours later. In the meantime the user will run into error messages, probably right after the first start and when opening an add or browser window.
    Restarting Anki won’t help this user.
    This user could solve all problems by just thinking of manually updating the add-ons. But my impression is that many users do not think of this. Again, this is just my experience based on my reddit support and getting bug reports for my add-ons on ankiweb.
    Avoiding all error messages even on the first start on Anki is complicated and not needed:
    If this line was something like if elap > 86_400 or is_first_start_with_a_new_anki_version the problem would mostly be solved: People might see an error message on the first start of the new anki version (because old add-on versions are loaded before the add-on check is called), but they would also get a dialog that tells them about new add-on versions and the need to restart anki on their first start of a new anki version.
    Implementing the part about or is_first_start_with_a_new_anki_version seemed like a quick fix that offers a good cost/benefit ratio. That’s why I proposed it.
    If I were to implement such a feature I’d store point_version() in the profile when a method like unloadProfileAndExit is called and then compare this stored value with point_version() in the method maybe_check_for_addon_updates.
    But I know how my code looks like and I know how your code looks like. So I just make threads like this one.

I won’t argue against a tooltip, which is fairly unobtrusive.
Checking for add-on updates after upgrading is a good idea without a doubt.

@rumo: thanks for quickly fixing this in your commit “Add last version check for add-on updates (#1608) · ankitects/anki@f6546c9 · GitHub” .