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.
I discover that each time an action occur in the reviewer, the deck
picker is updated. This is uselessly costly.
I tested and when going back to the deck picker, I still get the up to
date data immediately.
* We previously removed the camera permission from the manifest file (commit: fix: remove camera permission #14162, by Brayan). However, the code now includes a check for this permission that was introduced in commit 6a8ede0. Since th permission is not declared, this check fails, and the camera cannot be launched.
* The camera feature is declared in the manifest file as <uses-feature android:name="android.hardware.camera" /> rather than using <uses-permission android:name="android.permission.CAMERA" />. This omission causes the current permission
check to always return false, preventing users from accessing the camera options. This PR corrects that issue by removing that permission check.
