In this case, I really don't think it's realistic to expect an
OpChange from the backend. The backend already sends informations that
are relevant for the sync process. Given that "sync" does not uses the
processes uses for undoable change (indeed, it should not be
undoable), no OpChange is generated.
It seems reasonable in this place at least to directly notify the
observers.
Given that the observers expect an OpChanges, I create one, and simply
assume everything may be changed. This seems reasonable in case of
sync, and it's sufficiently rare that the cost won't be prohibitive
anyway.
Fixed: #16943Fixed: #16942
The DEL KeyEvent was previously declared to act as a keyboard shortcut
to delete the selected notes. After an initial search which registered
a search query entering DEL attempted to delete the current selected
notes which also resulted in another search(same input) being executed.
The fix registers the DEL keys as a delete notes shortcut ONLY if the
search box of the CardBrowser is not currently available(isIconified
returning true).
The previous code was showing the edit note screen every time the
E key was pressed, this was changed to only handle the E key event
as a shortcut only if the searchbox isn't currently available(
isIconified returning true).
The previous code was showing the tags filter dialog every time the
T key was pressed, this was changed to also introduce Ctrl as a
modifier like the documentation for the onKeyUp method recommends.
* Replaced the use of CropImageContract with CropImageView to ensure continued compatibility and adherence to best practices, updated related logic and UI.
* The decision to follow this migration path was influenced by the library's intent to depracte the CropImageContract see : https://redirect.github.com/CanHub/Android-Image-Cropper/pull/637
A user said:
> it asks whether the bug is specific to AnkiDroid twice
So we remove the second confirmation
> * What are the steps to reproduce? Alright, gimme a minute
> * Expected behavior? Does this have to be a separate field?
> * Actual behavior? Does this really have to be a separate field?
I have consolidated 'Expected' and 'Actual' behavior
> * Debug info? I... uhhh... ok, I give up.
> ...
> should probably elaborate this a bit, to make
> it more clear where to find this info
Since we've been using the new Settings for a while
I have made this less ambiguous
- Added `ChangeSubscriber` to subscribe the `ChangeManager` and monitor changes in the study queue (`OpChanges.studyQueues`).
- Implemented `opExecuted` in `ChangeSubscriber` to trigger `updateDeckPickerWidgets()` when relevant changes are detected.
- Introduced `WidgetAlarm`to handle the setting and cancellation of recurring alarms for widget updates.
- Added methods to create or retrieve `PendingIntent` instances associated with widgets.
- Ensured that alarms are set to trigger widget updates every one minute, avoiding multiple alarms for the same widget.
This commit introduces the Deck Picker Widget, which displays a list of decks along with the number of cards that are new, in learning, and due for review. It is a display-only widget.
Features:
- Displays deck names and statistics (new, learning, and review counts).
- Retrieves selected decks from shared preferences.
- Can be reconfigured by holding the widget.
This widget provides users with a quick overview of their decks without needing to open the app.
This PR:
- replicates the main UI seen in the desktop app
- removes information that isn't shown in the desktop app
like the total cards count and total new cards
- shows the bury counts + info message if the options for the deck allow it
Adds a complete implementation(+ supporting method) that follows the
desktop code.
See a179da3827/pylib/anki/scheduler/base.py (L69-L81)
See a179da3827/pylib/anki/decks.py (L188-L198)
Note that there was already a deckDueTree method defined in the
Scheduler class which didn't take any parameters and returned a
DeckNode. Ideally the two methods would be combined into one, this
was not done here because the full implementation returns a
nullable DeckNodeTree and the multiple call sites using the
parameterless method would require lots of changes.
SingleFragmentActivity was built with a call to setTransparentStatusBar()
which worked great for the initial Statistics page but currently the
activity can be used/is used with other fragments as well which don't
need this call(and results in undesired status bar foreground colors).
It seems it will never get used.
19-onboarding was not sent to crowdin for translation. So no need to
remove the file in other directories or update the translation script.
I was very surprised to see we used dynamic and not static one. I
tried to transform them into static shortcut, which seems cleaner. And
realized that we can't for a very absurd technical reason.
So I document it here, hoping nobody else will lose time on it.
