Add support for different Kitsu rating scales
Includes a database migration because we have been scaling Kitsu's
2-20 `ratingTwenty` integer value to a 1-10 (step 0.5) value and
stored that in the database.
I'm also "rounding" the values to the next lowest valid one in the
current rating system to mirror Kitsu's behaviour for this. Both Kitsu
and the app keep the misfit value around until the score is otherwise
edited, at which point the interface constrains the user selection to
only valid values (for the current system).
Maybe the RatingSystem data class is overkill, but a previous version
of mine had three constants for each system that had to be manually
associated at each corner. Encapsulating those in a little map of data
classes seemed the more ergonomic solution.
* Replace java.time APIs with kotlin(x).(date)time
kotlinx-datetime explicitly says in its README that it does not cover
i18n, so we have to stick with using their toJavaX converters wherever
we localise dates and times.
Yes, some of these replacements are... questionable. But I wanted to
try and maximise the replacement for now.
* Bump kotlinx-datetime to 0.8.0
* More kotlin.time/kotlinx-datetime replacements
* Remove redundant init block & make attributes val
* Replace new use of java.time.Instant
* Add support for MangaBaka
Note: missing a client ID which should be added by the project owner.
* Fix typo causing token refresh to fail
The field is called `refresh_token` not `refreshToken`, so all
token refreshes would fail with a 401.
* Use user-preferred score type
Currently, this only set once on login. When selecting a different
score type on MangaBaka, users (currently) will have to log out and
log in again in order for Mihon to refetch the score setting.
This appears to be what Mihon's AniList implementation does as well,
so I followed that.
* Fix score preference
Didn't get caught during the rebase.
* Fix finish_date
* Fix dates appearing offset
Timezone shenanigans meant Mihon was sending an ISO 8601 string for
the UTC timezone which lead to issues in non-UTC timezones.
For example:
1. User in UTC+1 selects 2026-03-22
2. Date picker returns 2026-03-22T00:00:00+01:00
3. MangaBakaApi converts that to an instant, converting it to UTC:
2026-03-21T23:00:00Z
4. MangaBaka receives that and sets all time components to 0
5. Mihon (when opening the track sheet next) receives:
2026-03-21T00:00:00Z
6. Mihon renders that as 2026-03-21
I figured out that MangaBaka accepts date-only strings as well, so we
just send those now.
* Remove fetching of total_chapters from MangaBaka
Currently, this information is not what Mihon needs for automatic
marking as COMPLETED since MangaBaka considers this an ongoing tally
of volume-published chapters rather than the final chapter number of a
title.
If anyone other than me used this code: Probably will have to unlink
& relink MB entries to get rid of the total_chapters data, not sure.
MangaBaka is currently considering a request from me to potentially
change this, but currently it's not what we need.
* Fix start date being reset on each read chapter
Admittedly a silly oversight. The other date-supporting trackers (AL,
MAL, Kitsu) use this check as opposed to `>= 0.0`.
* Add id: prefix search for MangaBaka
* Use new /v1/my/profile endpoint
Kindly added by the developers after my request <3.
* Change tracker ID to 11
* Remove unused import
* Identify Mihon in UA on all requests
* Use new `published.start_date` field for search
* Change Mihon's User Agent string for MangaBaka
- use MR.strings.app_name to avoid manual work for forks
- include app ID & commit sha for further distinction
* Add Changelog entry
* Add Mihon client ID
* Add OAuth state query param
This is?/will be? required by MangaBaka's auth provider and caused
linking issues for anyone who tried to link with MB in the past two
weeks or so.
* Update MangaBaka API URL
Changed as per MB announcement from 2026-05-27
* Use `titles` instead of old `title`
* Make title selection a method on MangaBakaItem
* Include ID in fallback title for easier reporting
Makes it a lot more intuitive for users.
Also reworded the message to more clearly direct users to the
Mangabaka Discord server instead of sounding like an instruction to
contact some "mangabaka" user in the Mihon Discord.
* `titles` is nullable
At least I noticed this before it was merged...
* Fix MangaBaka brand name
Co-authored-by: BrutuZ <7104931+BrutuZ@users.noreply.github.com>
* Remove Hikka comment
* Put MangaBaka at the top of the tracker list
AntsyLich decreed it to be like this.
Co-authored-by: AntsyLich <59261191+AntsyLich@users.noreply.github.com>
* Add display name support from #3533
* Fix changelog
* Rename MB icon to brand_mangabaka.webp
---------
Co-authored-by: BrutuZ <7104931+BrutuZ@users.noreply.github.com>
Co-authored-by: AntsyLich <59261191+AntsyLich@users.noreply.github.com>
This theme is mainly geared towards e-Ink displays with limited/no
colour capabilities. Previous themes like Yin & Yang would make heavy
use of greyscale colours which could look off on some devices.
This theme is probably not conformant to Material Design 3 colour
scheme guidelines, but it does boast some amazing WebAIM contrast
ratios (#FFFFFF text on #000000 background gets a ratio of 21:1, vice
versa too).
Initially, this was intended as a purely black and white theme but
some contrast issues arose, such as the download badges (tertiary
background, onTertiary text colour) having the same colour as unread
badges (primary/onPrimary), or the step indicators (stops) not being
visible on sliders (since they use the colours of the opposite state
track (active region stops are the colour of the inactive region track
and vice versa).
To mitigate this, each variant (dark/light) of the theme has one
additional grey mixed in for their tertiary and secondaryContainer
colours each. For the dark variant, this is a #A0A0A0 background for
#000000 text (8.03:1 contrast ratio) and for the light variant, it is
a #505050 background for #FFFFFF text (8.06:1 contrast ratio).
This results in distinct unread vs download badges and visible steps
in the sliders.
---------
Co-authored-by: Sunspark-007 <73711243+Sunspark-007@users.noreply.github.com>
Co-authored-by: AntsyLich <59261191+AntsyLich@users.noreply.github.com>
* add per Extension Incognito Mode
* migrate incognito sources when extension is updated
* remove incognito sources when extension is uninstalled
* remove not used variable
* address change requests
address change requests
* Rebase and cleanup code
---------
Co-authored-by: AntsyLich <59261191+AntsyLich@users.noreply.github.com>
* Add query to get chapter count by manga and chapter number
* Add functions to get chapter count by manga and chapter number
* Only count read chapters
* Add interactor
* Savepoint
* Extract new chapter logic to separate function
* Update javadocs
* Add preference to toggle new functionality
* Add todo
* Add debug logcat
* Use string resource instead of hardcoding title
* Add temporary logcat for debugging
* Fix detekt issues
* Update javadocs
* Update download unread chapters preference
* Remove debug logcat calls
* Update javadocs
* Resolve issue where read chapters were still being downloaded during manual manga fetch
* Apply code review changes
* Apply code review changes
* Revert "Apply code review changes"
This reverts commit 1a2dce78acc66a7c529ce5b572bdaf94804b1a30.
* Revert "Apply code review changes"
This reverts commit ac2a77829313967ad39ce3cb0c0231083b9d640d.
* Group download chapter logic inside the interactor GetChaptersToDownload
* Update javadocs
* Apply code review
* Apply code review
* Apply code review
* Update CHANGELOG.md to include the new feature
* Run spotless
* Update domain/src/main/java/mihon/domain/chapter/interactor/FilterChaptersForDownload.kt
---------
Co-authored-by: AntsyLich <59261191+AntsyLich@users.noreply.github.com>
AntsyLich