closes#5652
`col.fsrs_enabled` should be usable in any place where we have access to
the collection (And that doesn't involve building the queue or modifying
the config).
c.c. @user1823
fixes#5635
We could fix specifically the SM2 part of this bug with just the
"fsrs_enabled" part; but then if we encounter a card with the memory
state actually missing while reviewing I think we would get the same
error. So now any calculated memory state is only shown in the card info
and not writ to the database after being calculated.
Closes#5629
I decided to do this by moving safe mode to "app" rather than by moving
the rendering code to the main window
(2db70434ea1412b4513479236cd74464de986b6a)
If 2db70434ea1412b4513479236cd74464de986b6a is preferred then I'll
switch back to it
closes#5598
I tried to use a glob but it didn't like redirecting based on it ending
in .html 😢
```json
{
"source": "/:glob.html",
"destination": "/manual/:glob"
}
```
```json
{
"source": "/:glob*.html",
"destination": "/manual/:glob*"
}
```
Does not work. So I brute forced it.
closes#5064
Should let you quickly import to mintlify from the repos that use the
existing format.
a small problem that `DOCS_RELATIVE_LINK_REPLACEMENTS` needs to be set
manually for links between related translations but other than that
should be good.
I've run it on `en/addons` `en/faqs` `en/manual` and on `ar/manual`
`ar/faqs`. We might need to be careful to not overwrite any changes that
have been merged in this repo if there are any.
I've set it to copy only files where it can find them in the existing
mintlify docs because this allows us to more easily keep the site
structure. It does mean that there are some pages which aren't copied
and I'm going to have to look into that at some point.
But it should be good enough to look through and to import any remaining
changes left in the existing repos.
Example usage:
```
python tools/docs-converter.py [Source repo] [Target tab] [Target language code]
```
```
python tools/docs-converter.py ../anki-manual manual en
python tools/docs-converter.py ../anki-faqs faqs ar
```
---------
Co-authored-by: Abdo <abdo@abdnh.net>
Co-authored-by: Fernando Lins <1887601+fernandolins@users.noreply.github.com>
<!--
Title (for the Pull Request title field at the top):
Use a short prefix so the change type is obvious. You do not need to
repeat it in the body below.
Examples:
- fix: — bugfix
- feat: — feature
- refactor: — internal change without user-facing feature
- docs: — documentation only
- chore: — tooling, CI, deps, build housekeeping
- test: — tests only
-->
## Linked issue (required)
<!-- Fixes#123 / Closes#123 / Refs #123 -->
closes#4168
## Summary / motivation (required)
This PR makes it so that the font size of the text in the simulator
graph is consistent no matter how large the graph is.
## How to test (required)
Resize the graph in the simulator modals and the font size should remain
consistent
### Checklist (minimum)
- [X] I ran `./ninja check` or an equivalent relevant check locally.
- [ ] I added or updated tests when the change is non-trivial or
behavior changed.
### Details
<!-- Commands, manual steps, edge cases, and what you observed -->
## Before / after behavior (optional)
<!-- For bugfixes: behavior before vs after. For other types: N/A or a
short note. -->
## Risk / compatibility / migration (optional)
<!-- Breaking changes, rollout notes, or N/A for small / low-risk PRs
-->
## UI evidence (required for visual changes; otherwise N/A)
<!-- Screenshot or short video -->
Before:
[Screencast_20260703_204727.webm](https://github.com/user-attachments/assets/fe918dfb-18f1-4102-bc15-2ea48ad56b97)
After:
[Screencast_20260703_204516.webm](https://github.com/user-attachments/assets/c8a8db4c-6d3c-4868-b1a4-a03d81b91036)
## Scope
- [X] This PR is focused on one change (no unrelated edits).
---------
Co-authored-by: Lee Doughty <32392044+leedoughty@users.noreply.github.com>
closes#5284
> (self quote) As I see it. I can't think of a use for setting the
ignore_reviews_before value in the future. It also seems to result in
undefined behaviour so I think we should prevent it from being set like
that.
---------
Co-authored-by: Fernando Lins <1887601+fernandolins@users.noreply.github.com>
closes#3521
Previously when a card was moved between decks, it would be possible
that the FSRS data could be cleared from the card so that it wouldn't
display when the card stats were shown.
With this pr the memory state is attempted to be calculated when the
stats screen is opened if the state doesn't already exist.
## Testing steps
1. Create and review a card
2. Move it to a different deck
3. This card will now lack a memory state
4. Open the card stats
5. You will see the memory state there.
## Drawbacks
Notably means that the cards in the deck browser will still be missing
the memory state related columns after they're moved. It also introduces
an operation that modifies the card to the card_info function which
seems like a weird thing to do, although a similar thing is also done
when the user try's to simulate cards which are missing memory states.
This changed is predicated on what Dae said in the aformentioned issue:
> Deck changing is a common operation, and we don't want expensive
calculations every time it happens.
>
> Keeping the old memory state would require some extra flag so we know
to discard it at study time. And it would mean your stats are still
wrong - they'd just contain stale data, instead of missing data.
However with the memory state speed improvements introduced in #4335.
Maybe it is worth calculating the state when the cards are moved decks
rather than in this way?
closes#5149
`simulate_workload` spawns ~30 threads so might be a little expensive
for a test in that regard. It seems to work ok though.
---------
Co-authored-by: Fernando Lins <fernandolins@users.noreply.github.com>
<!--
Title (for the Pull Request title field at the top):
Use a short prefix so the change type is obvious. You do not need to
repeat it in the body below.
Examples:
- fix: — bugfix
- feat: — feature
- refactor: — internal change without user-facing feature
- docs: — documentation only
- chore: — tooling, CI, deps, build housekeeping
- test: — tests only
-->
## Linked issue (required)
<!-- Fixes#123 / Closes#123 / Refs #123 -->
closes#5001
This PR replaces the contents of `docs/` with symlinks to
`docs-site/developers/`
A caveat of this is that the metadata appears at the top of the file
instead of the title.
<img width="885" height="275" alt="image"
src="https://github.com/user-attachments/assets/430f9a71-e5a5-4412-983a-e4cfd7dc4714"
/>
We could either:
- Use ninja to copy the files from docs-site/developers and convert it
from .mdx to .md (Might be a problem with the symlink approach if mdx is
added to the contributor file later)
- Leave placeholder "For contribution instructions see: (link to
mintlify site)"s in the folder, which would have to wait until the
domain of the site is set. (Probably the best solution).
---------
Co-authored-by: Abdo <abdo@abdnh.net>
<!--
Title (for the Pull Request title field at the top):
Use a short prefix so the change type is obvious. You do not need to
repeat it in the body below.
Examples:
- fix: — bugfix
- feat: — feature
- refactor: — internal change without user-facing feature
- docs: — documentation only
- chore: — tooling, CI, deps, build housekeeping
- test: — tests only
-->
## Linked issue (required)
<!-- Fixes#123 / Closes#123 / Refs #123 -->
closes#4871
## How to test (required)
Find "Labs" as a new option in the preferences
### Checklist (minimum)
- [X] I ran `./ninja check` or an equivalent relevant check locally.
- [ ] I added or updated tests when the change is non-trivial or
behavior changed.
### Details
<!-- Commands, manual steps, edge cases, and what you observed -->
I've implemented the "Labs" feature in a web-view as I presume we are
moving away from QT and
Currently these options have no function. Before we can add the
functionality we should try and come up with the pattern that we should
use to register new flags.
## UI evidence (required for visual changes; otherwise N/A)
<img width="746" height="736" alt="image"
src="https://github.com/user-attachments/assets/28c4fd28-a593-4599-b43e-c2c23881251e"
/>
<img width="746" height="736" alt="image"
src="https://github.com/user-attachments/assets/c1cd69f9-3d8d-4866-a784-030b4274b4e7"
/>
## Scope
- [X] This PR is focused on one change (no unrelated edits).
<!--
Title (for the Pull Request title field at the top):
Use a short prefix so the change type is obvious. You do not need to
repeat it in the body below.
Examples:
- fix: — bugfix
- feat: — feature
- refactor: — internal change without user-facing feature
- docs: — documentation only
- chore: — tooling, CI, deps, build housekeeping
- test: — tests only
-->
## Linked issue (required)
fixes#4791
<!-- Fixes#123 / Closes#123 / Refs #123 -->
## Summary / motivation (required)
<!-- What this PR does and why. For larger changes, add enough context
for reviewers. -->
Previously, using set due date on a new card was broken for FSRS because
new cards didn't have a memory state which was how the set due date
function determined if FSRS is enabled or not. See
https://github.com/ankitects/anki/pull/4035#discussion_r2107488134.
This PR also makes it so that new cards behave as new cards after set
due date is used on them (Only while FSRS is enabled).
## Steps to reproduce (required, use N/A if not applicable)
<!-- Steps to reproduce: how to trigger the bug in the broken state (the
"before").
- Mainly for bugfixes;
- For bugs: numbered steps before the fix. For non-bugs: write N/A.
- use N/A for features, refactors, docs, chore, etc.
-->
1. create a new card
2. set it's due date
3. set it's due date again
4. the due date won't change
5. use grade now
6. the card will be scheduled based on the future date due date rather
than now
## How to test (required)
<!--- How to test: how you verified the change (checks, unit tests,
manual steps, edge cases — the "after" or general validation). --->
I followed the reproduction steps and instead, after using set due date
the card remains in a new state, and the saved interval is the inputted
number (with a minimum of one to prevent it appearing as a reset)
### Checklist (minimum)
- [X] I ran `./ninja check` or an equivalent relevant check locally.
- [ ] I added or updated tests when the change is non-trivial or
behavior changed.
### Details
<!-- Commands, manual steps, edge cases, and what you observed -->
## Before / after behavior (optional)
<!-- For bugfixes: behavior before vs after. For other types: N/A or a
short note. -->
## Risk / compatibility / migration (optional)
<!-- Breaking changes, rollout notes, or N/A for small / low-risk PRs
-->
If there are any ways I have not foreseen that an interval can be set to
0, then it may cause problems with this approach.
## UI evidence (required for visual changes; otherwise N/A)
<!-- Screenshot or short video -->
## Scope
- [X] This PR is focused on one change (no unrelated edits).
<!--
Title (for the Pull Request title field at the top):
Use a short prefix so the change type is obvious. You do not need to
repeat it in the body below.
Examples:
- fix: — bugfix
- feat: — feature
- refactor: — internal change without user-facing feature
- docs: — documentation only
- chore: — tooling, CI, deps, build housekeeping
- test: — tests only
-->
## Linked issue (required)
<!-- Fixes#123 / Closes#123 / Refs #123 -->
closes#5051
I used the regex
```regex
---\W+please see
```
to find redirect pages. I then checked that there wasn't a structural
reason to leave them before I deleted them. If there are any pages that
this method of searching left out LMK.
<!--
Title (for the Pull Request title field at the top):
Use a short prefix so the change type is obvious. You do not need to
repeat it in the body below.
Examples:
- fix: — bugfix
- feat: — feature
- refactor: — internal change without user-facing feature
- docs: — documentation only
- chore: — tooling, CI, deps, build housekeeping
- test: — tests only
-->
## Linked issue (required)
<!-- Fixes#123 / Closes#123 / Refs #123 -->
## Summary / motivation (required)
closes https://github.com/ankitects/anki/issues/4978
<!-- What this PR does and why. For larger changes, add enough context
for reviewers. -->
## Steps to reproduce (required, use N/A if not applicable)
<!-- Steps to reproduce: how to trigger the bug in the broken state (the
"before").
- Mainly for bugfixes;
- For bugs: numbered steps before the fix. For non-bugs: write N/A.
- use N/A for features, refactors, docs, chore, etc.
-->
1. press "optimize all presets"
2. the window will save the current settings and cloze after it is done.
## How to test (required)
<!--- How to test: how you verified the change (checks, unit tests,
manual steps, edge cases — the "after" or general validation). --->
after pressing optimize all presets, you should be prompted if you want
to save. After confirming you want to save, the window will remain open
when the process completes.
### Checklist (minimum)
- [X] I ran `./ninja check` or an equivalent relevant check locally.
- [ ] I added or updated tests when the change is non-trivial or
behavior changed.
### Details
<!-- Commands, manual steps, edge cases, and what you observed -->
## Before / after behavior (optional)
<!-- For bugfixes: behavior before vs after. For other types: N/A or a
short note. -->
## Risk / compatibility / migration (optional)
<!-- Breaking changes, rollout notes, or N/A for small / low-risk PRs
-->
## UI evidence (required for visual changes; otherwise N/A)
<!-- Screenshot or short video -->
## Scope
- [X] This PR is focused on one change (no unrelated edits).
<!--
Title (for the Pull Request title field at the top):
Use a short prefix so the change type is obvious. You do not need to
repeat it in the body below.
Examples:
- fix: — bugfix
- feat: — feature
- refactor: — internal change without user-facing feature
- docs: — documentation only
- chore: — tooling, CI, deps, build housekeeping
- test: — tests only
-->
## Linked issue (required)
<!-- Fixes#123 / Closes#123 / Refs #123 -->
fixes#5006
## Steps to reproduce (required, use N/A if not applicable)
<!-- Steps to reproduce: how to trigger the bug in the broken state (the
"before").
- Mainly for bugfixes;
- For bugs: numbered steps before the fix. For non-bugs: write N/A.
- use N/A for features, refactors, docs, chore, etc.
-->
> I. Undo duplication
>
> (1) Write into the editor “line”.
>
> (2) In the non html editor, select this line, then press the
unordered/ordered list button in the tool bar (or use keyword shortcut);
the html field of the editor becomes
>
> ```
> <ol><li>line</li></ol>
>
> ```
>
> (3) Press the undo shortcut (command + Z on Mac)
>
> Result: the list is still there, but its content is duplicated after
the list; the html field reads:
>
> ```
> <ol><li>line</li></ol>line
>
> ```
>
> Remark: the same bug occurs when we begin with multiple lines instead
of just one.
## How to test (required)
<!--- How to test: how you verified the change (checks, unit tests,
manual steps, edge cases — the "after" or general validation). --->
Follow the reproduction steps. Undo should remove the text in the order
that it appeared.
### Checklist (minimum)
- [X] I ran `./ninja check` or an equivalent relevant check locally.
- [ ] I added or updated tests when the change is non-trivial or
behavior changed.
## Risk / compatibility / migration (optional)
<!-- Breaking changes, rollout notes, or N/A for small / low-risk PRs
-->
Undoes some of the behaviour from #3483. I couldn't reproduce the bug he
mentioned with this patch but I'm not entirely sure this doesn't re
introduce https://github.com/ankitects/anki/issues/3338 as a bug.
## Scope
- [X] This PR is focused on one change (no unrelated edits).
<!--
Title (for the Pull Request title field at the top):
Use a short prefix so the change type is obvious. You do not need to
repeat it in the body below.
Examples:
- fix: — bugfix
- feat: — feature
- refactor: — internal change without user-facing feature
- docs: — documentation only
- chore: — tooling, CI, deps, build housekeeping
- test: — tests only
-->
These pages are in the repo but are not used by the docs.
closes#5050
<!--
Title (for the Pull Request title field at the top):
Use a short prefix so the change type is obvious. You do not need to
repeat it in the body below.
Examples:
- fix: — bugfix
- feat: — feature
- refactor: — internal change without user-facing feature
- docs: — documentation only
- chore: — tooling, CI, deps, build housekeeping
- test: — tests only
-->
## Linked issue (required)
closes#5011
All the "apps.ankiweb.net" Are broken in the form that they currently
exist which makes it difficult to confirm my changes would link to the
correct files so I've left them as they are in this pr.
---------
Co-authored-by: Abdo <abdo@abdnh.net>
<!--
Title (for the Pull Request title field at the top):
Use a short prefix so the change type is obvious. You do not need to
repeat it in the body below.
Examples:
- fix: — bugfix
- feat: — feature
- refactor: — internal change without user-facing feature
- docs: — documentation only
- chore: — tooling, CI, deps, build housekeeping
- test: — tests only
-->
## Linked issue (required)
<!-- Fixes#123 / Closes#123 / Refs #123 -->
Fixes#4992
## Summary / motivation (required)
<!-- What this PR does and why. For larger changes, add enough context
for reviewers. -->
This prevents the webview refreshing from affecting the styling of the
page.
## Steps to reproduce (required, use N/A if not applicable)
<!-- Steps to reproduce: how to trigger the bug in the broken state (the
"before").
- Mainly for bugfixes;
- For bugs: numbered steps before the fix. For non-bugs: write N/A.
- use N/A for features, refactors, docs, chore, etc.
-->
1. Load an anki webview
2. Refresh it (Using the ankiview web inspector addon or otherwise)
3. The body will have none of the classes on it and none of the other
styling will be applied
## How to test (required)
<!--- How to test: how you verified the change (checks, unit tests,
manual steps, edge cases — the "after" or general validation). --->
Follow the reproduction steps and the classes should be the same as
before
### Checklist (minimum)
- [X] I ran `./ninja check` or an equivalent relevant check locally.
- [ ] I added or updated tests when the change is non-trivial or
behavior changed.
### Details
<!-- Commands, manual steps, edge cases, and what you observed -->
## Before / after behavior (optional)
<!-- For bugfixes: behavior before vs after. For other types: N/A or a
short note. -->
Before (After a refresh):
<img width="644" height="103" alt="image"
src="https://github.com/user-attachments/assets/888c1794-ed1a-447f-8b14-6cc631a1a1d3"
/>
After (After a refresh):
<img width="644" height="103" alt="image"
src="https://github.com/user-attachments/assets/49a7d6af-0292-4907-8faa-258d94190663"
/>
## Risk / compatibility / migration (optional)
<!-- Breaking changes, rollout notes, or N/A for small / low-risk PRs
-->
## UI evidence (required for visual changes; otherwise N/A)
<!-- Screenshot or short video -->
## Scope
- [X] This PR is focused on one change (no unrelated edits).
<!--
Title (for the Pull Request title field at the top):
Use a short prefix so the change type is obvious. You do not need to
repeat it in the body below.
Examples:
- fix: — bugfix
- feat: — feature
- refactor: — internal change without user-facing feature
- docs: — documentation only
- chore: — tooling, CI, deps, build housekeeping
- test: — tests only
-->
## Linked issue (required)
closes#5018
<!-- Fixes#123 / Closes#123 / Refs #123 -->
## Summary / motivation (required)
This prevents large diffs with prettier being used with the mintlify
editor
A caveat of this is that the docs generated by cog now have to be
prettier compatible. Also for some reason prettier has problems with the
{/* */} multi-line comment format so we have to use <!-- --> instead.
Sadly I don't have a good way to check that the Prettier config does not
differ between this PR and the editor.
---------
Co-authored-by: Abdo <abdo@abdnh.net>
- Updated docs-site/manual/getting-started.mdx
- Deleted docs-site/manual/index.mdx
- Updated docs-site/docs.json
Mintlify-Source: dashboard-editor
Please note that the Mintlify editor seems to make formatting changes to
files which it edits which makes this diff large than necessary.
closes#5000
Uses the introduction / getting started pages as the index for each
category rather than a list of links.
Also re-introduces some pages that were missing from the FAQ to use as
the index as well.
I'm sorry about the large diff but mintlify makes formatting changes
when you use the editor.
---------
Co-authored-by: mintlify[bot] <109931778+mintlify[bot]@users.noreply.github.com>
<!--
Title (for the Pull Request title field at the top):
Use a short prefix so the change type is obvious. You do not need to
repeat it in the body below.
Examples:
- fix: — bugfix
- feat: — feature
- refactor: — internal change without user-facing feature
- docs: — documentation only
- chore: — tooling, CI, deps, build housekeeping
- test: — tests only
-->
## Linked issue (required)
<!-- Fixes#123 / Closes#123 / Refs #123 -->
What I used to complete #4916
## Summary / motivation (required)
<!-- What this PR does and why. For larger changes, add enough context
for reviewers. -->
If we need to add more github actions in future this should make it easy
---------
Co-authored-by: Abdo <abdo@abdnh.net>
<!--
Title (for the Pull Request title field at the top):
Use a short prefix so the change type is obvious. You do not need to
repeat it in the body below.
Examples:
- fix: — bugfix
- feat: — feature
- refactor: — internal change without user-facing feature
- docs: — documentation only
- chore: — tooling, CI, deps, build housekeeping
- test: — tests only
-->
## Linked issue (required)
<!-- Fixes#123 / Closes#123 / Refs #123 -->
closes#4983
## Summary / motivation (required)
<!-- What this PR does and why. For larger changes, add enough context
for reviewers. -->
This pr adds links to the aqt section of the docs.
### Details
<!-- Commands, manual steps, edge cases, and what you observed -->
## UI evidence (required for visual changes; otherwise N/A)
<img width="306" height="111" alt="image"
src="https://github.com/user-attachments/assets/39111e4f-8aa1-4865-b193-0da949967618"
/>
## Scope
- [X] This PR is focused on one change (no unrelated edits).
---------
Co-authored-by: Abdo <abdo@abdnh.net>
<!--
Title (for the Pull Request title field at the top):
Use a short prefix so the change type is obvious. You do not need to
repeat it in the body below.
Examples:
- fix: — bugfix
- feat: — feature
- refactor: — internal change without user-facing feature
- docs: — documentation only
- chore: — tooling, CI, deps, build housekeeping
- test: — tests only
-->
## Linked issue (required)
<!-- Fixes#123 / Closes#123 / Refs #123 -->
closes#4722
## Summary / motivation (required)
<!-- What this PR does and why. For larger changes, add enough context
for reviewers. -->
I used this nice script I found:
https://gist.github.com/onnimonni/3462f958c7d235417863651974514525
For the reasons behind this change see:
- #4722
## Steps to reproduce (required, use N/A if not applicable)
<!-- Steps to reproduce: how to trigger the bug in the broken state (the
"before").
- Mainly for bugfixes;
- For bugs: numbered steps before the fix. For non-bugs: write N/A.
- use N/A for features, refactors, docs, chore, etc.
-->
(N/A)
## How to test (required)
<!--- How to test: how you verified the change (checks, unit tests,
manual steps, edge cases — the "after" or general validation). --->
See it run in my repo here:
https://github.com/Luc-Mcgrady/anki/actions/runs/26718877866
### Checklist (minimum)
- [X] I ran `./ninja check` or an equivalent relevant check locally.
- [ ] I added or updated tests when the change is non-trivial or
behavior changed.
### Details
<!-- Commands, manual steps, edge cases, and what you observed -->
## Before / after behavior (optional)
<!-- For bugfixes: behavior before vs after. For other types: N/A or a
short note. -->
## Risk / compatibility / migration (optional)
<!-- Breaking changes, rollout notes, or N/A for small / low-risk PRs
-->
## UI evidence (required for visual changes; otherwise N/A)
<!-- Screenshot or short video -->
## Scope
- [X] This PR is focused on one change (no unrelated edits).
<!--
Title (for the Pull Request title field at the top):
Use a short prefix so the change type is obvious. You do not need to
repeat it in the body below.
Examples:
- fix: — bugfix
- feat: — feature
- refactor: — internal change without user-facing feature
- docs: — documentation only
- chore: — tooling, CI, deps, build housekeeping
- test: — tests only
-->
## Linked issue (required)
<!-- Fixes#123 / Closes#123 / Refs #123 -->
fixes https://github.com/ankitects/anki/issues/4795
## Summary / motivation (required)
An error appeared in the console of the deck options. with this change
it doesn't.
<!-- What this PR does and why. For larger changes, add enough context
for reviewers. -->
## Steps to reproduce (required, use N/A if not applicable)
<!-- Steps to reproduce: how to trigger the bug in the broken state (the
"before").
- Mainly for bugfixes;
- For bugs: numbered steps before the fix. For non-bugs: write N/A.
- use N/A for features, refactors, docs, chore, etc.
-->
1. open the deck options
2. check the console either by using the Anki command line or by using
[this addon](https://ankiweb.net/shared/info/31746032)
## How to test (required)
<!--- How to test: how you verified the change (checks, unit tests,
manual steps, edge cases — the "after" or general validation). --->
The console should be clear on the deck options page
### Checklist (minimum)
- [X] I ran `./ninja check` or an equivalent relevant check locally.
- [ ] I added or updated tests when the change is non-trivial or
behavior changed.
### Details
<!-- Commands, manual steps, edge cases, and what you observed -->
## Before / after behavior (optional)
<!-- For bugfixes: behavior before vs after. For other types: N/A or a
short note. -->
## Risk / compatibility / migration (optional)
<!-- Breaking changes, rollout notes, or N/A for small / low-risk PRs
-->
## UI evidence (required for visual changes; otherwise N/A)
<!-- Screenshot or short video -->
## Scope
- [X] This PR is focused on one change (no unrelated edits).
<!--
Title (for the Pull Request title field at the top):
Use a short prefix so the change type is obvious. You do not need to
repeat it in the body below.
Examples:
- fix: — bugfix
- feat: — feature
- refactor: — internal change without user-facing feature
- docs: — documentation only
- chore: — tooling, CI, deps, build housekeeping
- test: — tests only
-->
## Linked issue (required)
closes https://github.com/ankitects/anki/issues/4809
<!-- Fixes#123 / Closes#123 / Refs #123 -->
## Summary / motivation (required)
<!-- What this PR does and why. For larger changes, add enough context
for reviewers. -->
This exposes a JS api to set the speed at which you click to unlock the
FSRS parameters (See #4372)
## Steps to reproduce (required, use N/A if not applicable)
<!-- Steps to reproduce: how to trigger the bug in the broken state (the
"before").
- Mainly for bugfixes;
- For bugs: numbered steps before the fix. For non-bugs: write N/A.
- use N/A for features, refactors, docs, chore, etc.
-->
N/A
## How to test (required)
<!--- How to test: how you verified the change (checks, unit tests,
manual steps, edge cases — the "after" or general validation). --->
Open the console in the deck options and run
`anki.setParameterUnlockClickTimeoutMs(0)`. If you set it to 0 then it
will be impossible to unlock. if you set it to something very high it
will be very easy.
### Checklist (minimum)
- [X] I ran `./ninja check` or an equivalent relevant check locally.
- [ ] I added or updated tests when the change is non-trivial or
behavior changed.
### Details
<!-- Commands, manual steps, edge cases, and what you observed -->
## Before / after behavior (optional)
<!-- For bugfixes: behavior before vs after. For other types: N/A or a
short note. -->
## Risk / compatibility / migration (optional)
<!-- Breaking changes, rollout notes, or N/A for small / low-risk PRs
-->
## UI evidence (required for visual changes; otherwise N/A)
<!-- Screenshot or short video -->
## Scope
- [X] This PR is focused on one change (no unrelated edits).
* Feat/Disable parameter editing until right clicked 3 times
* wording
* use left click
* Change placeholder to text
* use diabled agaain
* Add warning box
* FSRS
* Added: Timeout ms
* a11y
* Fix: typo
* Fix: Text selection issue
* backend part
* split memorised and cost
* slapdash frontend
* extract some simulator logic
* Add zoomed version of graph
* ./check
* Fix: Tooltip
* Fix: Simulator/workload transition
* remove "time"
* Update ts/routes/graphs/simulator.ts
Co-authored-by: user1823 <92206575+user1823@users.noreply.github.com>
* Added: Mode toggle
* Disable Dr in workload mode
* keep button order consistant between modes
* dont clear points on mode swap
* add review count graph
* Revert "dont clear points on mode swap"
This reverts commit fc89efb1d9.
* "Help me pick" button
* unrelated title case change
* Add translation strings
* fix: missing translation string
* Fix: Layout shift
* Add: Experimental
* Fix Time / Memorized
* per day values
* set review limit to 9999 on open
* keep default at currently set value
* Do DR calculation in parallel (dae)
Approx 5x faster on my machine
---------
Co-authored-by: user1823 <92206575+user1823@users.noreply.github.com>
Co-authored-by: Damien Elmes <gpg@ankiweb.net>
* Feat/Add legacy evaluate config bool
* Minor tweaks based on PR suggestions (dae)
New enabling command:
from anki.config import Config
mw.col.set_config_bool(Config.Bool.FSRS_LEGACY_EVALUATE, True)
* use non breaking spaces for names on about page
* Update qt/aqt/about.py
Co-authored-by: llama <gh@siid.sh>
---------
Co-authored-by: llama <gh@siid.sh>
* Fix: Recalculate memory states on simulate
* Fix: Wrong cards included
* Save states to cards
* ./check
* Update rslib/src/scheduler/fsrs/simulator.rs
* Added: Leech suspend to simulator
* Added: leech threshold spin box
* Update git rev
* Added: Save to preset options
* ./check
* Added: "Advanced settings" dropdown
* Removed: Indent
* Added: Easy days
* Added: Sticky header
* Removed: Easy Day updating without saving
* un-nest disclosure
* bump fsrs
* Update a VSCode setting to match recent releases
* Move Easy Days above the Advanced settings
I think it's a bit more logical to have Advanced come last.
* Ensure graph fits inside screen height
* Bump fsrs version
* Subtract introduced:1 count from learn count of first day of simulator.
* Fix: Cards filtered
* Tidy up
* Fix: Cards filtered (2)
* ./check
* Removed unnecessary filter
* Fix: Doesn't work for real new cards
* ./check
* Fix: .is_none()
* Limit to 1 day
* Removed "days_to_simulate" argument from convert
* Fix: min value for Additional new cards not 0
* Fix: New cards/day default value not starting value
* Preset defaults for review intervals and per day.
* Fix: "Additional new cards to simulate" localisation
* Revert "Fix: "Additional new cards to simulate" localisation"
This reverts commit 9be61d9f93.
Luc Mcgrady