Our average calculation is based on pre-binned values, so it's not
entirely accurate, but using the midpoint of the bin brings us closer.
In the future we can solve this by calculating it on the Rust end instead.
Confirmed correct layout in RTL mode.
I experimented with adding a tooltip as well, as suggested in
https://forums.ankiweb.net/t/anki-23-12-beta/37771/82, but it's
confusing as we already change the mouse cursor/underline when the user
hovers over a label. Given the help text universally starts with
"affects the entire collection", I think that's good enough.
- We were registered another event handler for each card, which was a
resource leak, and would lead to the shortcut failing on every second card
due to the even number of toggles.
- We were allowing toggleMasks() to run even when the button wasn't visible
(e.g., when showing the question side of a card)
The previous wording could be interpreted as 'time until showing question'
or 'time that question should be shown'. I'd intended the latter, and
I didn't notice that the original implementation was doing the former.
This reverts commit abd8759d50.
Rolling this back for now, as it's caused a couple of regressions:
- In the old path, we returned (html, internal=False); in the new path,
it's returned as internal=True, which prevents formatting from being
stripped. This requires night mode to reproduce, as we don't strip text
colors in day mode.
- It can result in lost alt tags and filenames, as after right clicking on an
image in Chrome and choosing 'copy image', Chrome puts both the HTML and
the image on the clipboard
Related discussion: https://forums.ankiweb.net/t/anki-23-12-beta/37771/90
Profiling revealed that binding to clientWidth for each component in
the deck options was taking up a sizable amount of time, due to the
inefficient way it's implemented: https://github.com/sveltejs/svelte/issues/7583
In one case, we can instead defer checking clientWidth until we go to
display the popover. In the other case, we can achieve the revert button
positioning a different way.
The last change dropped the speed index in Chrome from 1.4s to 1s; this
change brings it down to 0.7s.
Also fixed the hovered select element from jiggling due to a different
border width when hovering.
There's been a fair bit of talk on the forums about users not discovering
the help info, so this will hopefully make finding it easier.
Ideally we'd use a single var(--fg), but it feels a bit too strong in
light mode.
The animations we were showing on hover/focus made the UI feel
laggy. This has come up before, and we already disable them for buttons.
I experimented with removing the transitions (but keeping the change on
hover) - it feels much more responsive, but I also didn't feel that it
was contributing anything useful - the user knows where they've placed
the mouse or cursor, and the extra movement feels like a bit of a
distraction. Happy to discuss if people feel differently, though.
column-count was causing progressively-worse performance. By switching
to manual left/right column assignment, we get faster performance and
retain the top-to-bottom/left-to-right flow.
This also removes the outer DynamicallySlottable, which as far as I'm
aware, is not used by any add-ons.
Closes#2877
Message arrived on a background non-Qt thread, and called run_in_background(),
which assumes it's running on the GUI thread. This resulted in single_shot()
failing to run in reviewer's on_av_player_did_end_playing on Linux/macOS.
* Ignore rescheduled cards in old stats page
Rescheduled cards are not actual reviews. So, including them in Cards Studied Today is inappropriate.
* Simplify SQL query
* Fix Answer Buttons graph
* Fix error
* Potentially fix error
