* Replace deprecated rememberPlainTooltipPositionProvider
* Remove superfluous when branch
This when is marked as exhaustive.
* Replace deprecated LibrariesContainer call
AboutLibraries now wants us to produce the libraries ourselves.
* Replace deprecated ClipboardManager with Clipboard
Clipboard uses suspend functions, hence the coroutine scope addition.
* Use multi-dollar strs to simplify GraphQL queries
These have been available since Kotlin 2.1.
* Remove various redundant casts & conversions
- WebViewScreenContent: loadingState is in the LoadingState.Loading
branch, no need to cast at all
- Bangumi: username is not modified, make val
- Kavita: token is already a String
- PagerViewerAdapter: insertPageLastPage is already null-checked
- PagerViewerAdapter: use reified filterIsInstance
- ReaderViewModel: chapter IDs are already Longs
- CloudflareInterceptor: webview is smart-cast to non-null here
* Replace deprecated MenuAnchorType
Literally just a typealias for ExposedDropdownMenuAnchorType anyway.
* OptimizeNonSkippingGroups is enabled by default
* Suppress shadowing warning
This is explicitly intentional according to the KDocs.
* Migrate Context Receivers to Context Parameters
Requires changing the compiler arg, but that is part of the migration:
https://blog.jetbrains.com/kotlin/2025/04/update-on-context-parameters
Apparently, the only visible change is that names are required now.
"_" can be used for anonymous context parameters.
* Fix expression bodies with explicit return
Naming conflict resolved by aliasing.
From 2.4/2.5 onward, these will only be allowed with explicit return
types, or have to be turned into a block body. I opted for the latter
since the function is reasonably dense already.
see: https://youtrack.jetbrains.com/issue/KTLC-288
* Suppress deprecation of non-AutoMirrored icons
We use these arrows for navigation in the Upcoming screen.
I strongly doubt the AutoMirrored versions would make sense for our
use-case.
* Explicitly opt-in to new annotation default rules
affects the following annotated value-parameters:
- Preference.SliderPreference.steps (`@IntRange`)
- ReaderViewModel.State.brightnessOverlayValue (`@IntRange`)
- ReadingMode.iconRes (`@DrawableRes`)
- MigrationListScreenModel.Dialog.Progress.progress (`@FloatRange`)
see: https://youtrack.jetbrains.com/issue/KT-73255
see: https://github.com/Kotlin/KEEP/blob/change-defaulting-rule/proposals/annotation-target-in-properties.md
Warning message was the following:
This annotation is currently applied to the value parameter only, but in the future it will also be applied to field.
- To opt in to applying to both value parameter and field, add '-Xannotation-default-target=param-property' to your compiler arguments.
- To keep applying to the value parameter only, use the '@param:' annotation target.
(cherry picked from commit b543bc089a442c5e93b0fb6c83bc4037740b1eb5)
# Conflicts:
# app/src/main/java/eu/kanade/tachiyomi/ui/reader/viewer/pager/PagerViewerAdapter.kt
# core/common/src/main/kotlin/eu/kanade/tachiyomi/network/interceptor/CloudflareInterceptor.kt
# core/common/src/main/kotlin/mihon/core/common/archive/ArchiveInputStream.kt
* Add Filters to Updates screen
Behaves basically like the filters in the library:
- Unread: Show/Don't show unread chapters
- Downloaded: Show/Don't show downloaded chapters
- Started: Show/Don't show chapters that have some progress but aren't
fully Read
- Bookmarked: Show/Don't show chapters that have been bookmarked
Started behaves differently from its Library counterpart because the
actual manga data is not available at this point in time and I thought
calling getManga for each entry without caching would be a pretty bad
idea.
I have modelled this closely on the filter control flow in the
Library, but I'm sure this can be simplified/adjusted in some way.
* Move most filtering logic to SQL
Unread, Started, and Bookmarked filters are now part of the SQL query.
Download state cannot be filtered in the database so it remains in
Kotlin.
Because the Downloaded filter has to be run in Kotlin, the combine
flow uses the preferences flow twice, once to get the SQL query params
and once for the Kotlin filters (only Downloaded at this time).
* Add "Hide excluded scanlators" to update filters
Based on the work done in #1623 but integrated with the other filters
in this PR. Added the user as a co-author for credit.
Co-authored-by: Dani <17619547+shabnix@users.noreply.github.com>
---------
Co-authored-by: Dani <17619547+shabnix@users.noreply.github.com>
(cherry picked from commit bbe9aa8561360f030072fbc49f79748e71c6535e)
# Conflicts:
# CHANGELOG.md
# app/src/main/java/eu/kanade/tachiyomi/di/PreferenceModule.kt
# data/src/main/java/tachiyomi/data/updates/UpdatesRepositoryImpl.kt
# data/src/main/sqldelight/tachiyomi/migrations/9.sqm
# domain/src/main/java/tachiyomi/domain/updates/interactor/GetUpdates.kt
One of these days I'll get through a tracker change without
nullability problems...
(cherry picked from commit edcf84d9022e7436606a0b8c493c1035888ac60a)
Due to a `Float->Double->Float` conversion somewhere inside Mihon, the
tracker sees 2.1 as 2.0999999046325684, which means this filter ignores
the 2.1 chapter (which we just tried to mark as read). This small
epsilon is small enough to never bother any serious usage, but large
enough to ignore any such conversion errors.
Co-authored-by: AntsyLich <59261191+AntsyLich@users.noreply.github.com>
(cherry picked from commit bd5c4d48f980d2d3dcc1112fe499dba17ef8e507)
# Conflicts:
# CHANGELOG.md
Previously, the app made one request for the search, and then fired
off 1 request per search result to obtain additional data, such as
each title's synopsis, etc.
However, MAL's search allows field selection during the initial query,
which will return all the data in that first response, avoiding the
massive bunch of requests (and alleviating some pressure on MAL from
our userbase).
By combining the selected fields into one constant, I was able to also
get rid of the MALUserListSearch entirely because it was redundant.
This allows for a unified MALManga->TrackSearch helper, further
reducing complexity.
I got to my "11x" improvement because on page of search results has 10
elements, and this change turns 11 (1+10 for results) requests into 1.
(cherry picked from commit 9bf2d78a421213b1885456f5b54c3286edc539e1)
# Conflicts:
# CHANGELOG.md
# app/src/main/java/eu/kanade/tachiyomi/data/track/myanimelist/MyAnimeListApi.kt
* feat: Add sync events to SyncYomi
Now it will send the events back to `SyncYomi` server and then forward those to the notifications services that are enabled, such as discord, telegram, and etc.
* chore: fix build error.
A user in #2777 was using the ComicInfo.xml Year/Month/Day fields to
indicate date of publication for some American comics, which often
predate the UNIX Epoch of 1970.
They were seeing "N/A" displays because this line of code discarded
date information for any time before Jan 1st, 1970.
The `toRelativeString` extension function used in the other
`relativeDateText` function already accounts for very distant dates
(anything >7 days away turns into full date, not relative, regardless
of setting, though disabling the relative timestamp setting
circumvents this with the same result). Removing this line should not
cause any issues as it is purely a display difference and the use case
of backdating comics to pre-1970 is worth it in my opinion.
(cherry picked from commit 7a1c8a1b61e07d2e1a402b5daf0e7c04c232f655)
# Conflicts:
# CHANGELOG.md
* Include romanized titles of the original language in description
* Implement handling for `finalChapterInDesc` preference.
* Handle `preferExtensionLangTitle` preference when fetching manga details.
* Address some warnings, clean up unused code and spotless apply.
Jobobby04