We need to filter by language and region together because there is
slightly different logic:
1) if there is the exact match language+region then use it
2) if there is the language WITHOUT region match then use it
3) in other cases use items WITHOUT language and region qualifiers at
all
Given resources:
values
values-en-rUS
values-de
Filter results:
"en" -> values
"en-US" -> values-en-rUS
"en-GB" -> values
"de-IT" -> values-de
fixes https://github.com/JetBrains/compose-multiplatform/issues/4571
Adds a public `Res.getUri(path: String): String` function.
It lets external libraries a way to read resource files by a platform
dependent Uri.
E.g.: video players, image loaders or embedded web browsers.
```kotlin
val uri = Res.getUri("files/my_video.mp4")
```
fixes https://github.com/JetBrains/compose-multiplatform/issues/4360
The issue was in a case where there wasn't a direct dependency on the
skiko artifact, the task would attempt to get one at task execution
time. This moves that to task configuration time.
Users noticed if an app has big a `string.xml` file it affects the app
startup time:
https://github.com/JetBrains/compose-multiplatform/issues/4537
The problem is slow XML parsing.
Possible ways for optimization:
1) inject text resources direct to the source code
2) convert XMLs to an optimized format to read it faster
We selected the second way because texts injected to source code have
several problems:
- strict limitations on text size
- increase compilation and analysation time
- affects a class loader and GC
> Note: android resources do the same and converts xml values to own
`resources.arsc` file
Things was done in the PR:
1) added support any XML files in the `values` directory
2) **[BREAKING CHANGE]** added `Res.array` accessor for string-array
resources
3) in a final app there won't be original `values*/*.xml` files. There
will be converted `values*/*.cvr` files.
4) generated code points on string resources as file -> offset+size
5) string resource cache is by item now (it was by the full xml file
before)
6) implemented random access to read CVR files
7) tasks for syncing ios resources to a final app were seriously
refactored to support generated resources (CVR files)
8) restriction for 3-party resources plugin were deleted
9) Gradle property `compose.resources.always.generate.accessors` was
deleted. It was for internal needs only.
Fixes https://github.com/JetBrains/compose-multiplatform/issues/4537
Ports a part of Unicode's ICU in pure Kotlin and implements
Android-style plural string resource support. Fixes
JetBrains/compose-multiplatform#425.
# Changes
- Added `org.jetbrains.compose.resources.intl.{PluralCategory,
PluralRule, PluralRuleList}`, which parses and evaluates scripts in
Unicode's Locale Data Markup Langauge.
- Copied `plurals.xml` from Unicode's
[CLDR](https://github.com/unicode-org/cldr/blob/release-44-1/common/supplemental/plurals.xml).
- Added `GeneratePluralRuleListsTask`, which parses `plurals.xml` and
generates required Kotlin source codes.
- Added `PluralStringResource`, `pluralStringResource`, or
`getPluralString`, corresponding to `StringResource`, `stringResource`,
or `getString`.
- Modified `ResourcesSpec.kt` so the generated `Res` class exposes
`Res.plurals`.
# Potential Further Improvements
- [ ] Allow configuring the default language in the `compose.resources
{}` block (#4482) to determine the default pluralization rule (or just
presume English as default)
- [ ] Move the parser logic to the Gradle plugin and generate
pluralization rules in `Res` only for languages used in
`composeResources`
---------
Co-authored-by: Konstantin Tskhovrebov <konstantin.tskhovrebov@jetbrains.com>
This PR updates the experimental CLI example to the latest Kotlin and
Compose Multiplatform releases.
The default platform used was also updated to Mac arm64.
Co-authored-by: Christian Melchior <christian.melchior@jetbrains.com>
# Changes
* Add `Never` to `enum class ResourceClassGeneration` to disable the
generation of Res class in the gradle plugin
# Motivation
As the [comment in issue
4229](https://github.com/JetBrains/compose-multiplatform/issues/4229#issuecomment-2008626808)
said, my team is not in the ecosystem of gradle, but organize the build
steps in bazel. We want to follow the files layout but just disable the
generation task of gradle and handle it by outself.
Steps to reproduce:
1) Add a 'font-en' directory with a font to an android app with compose
resources
2) build the app with `assembleDebug` and check that a corresponding dir
is presented in the final APK
3) rename a qualifier of the dir to `font-de`
4) re-build the app with the same command `assembleDebug`
Expected: the new APK will contain the new font dir
Actual: the new APK doesn't have the new font dir but has old one
'font-en'
The PR fixes that
There is a bug on iOS:
```
NSLocale.currentLocale() -> 'en-US'
NSLocale.preferredLanguages().first().let { NSLocale(it as String) } -> 'ru'
```
An equal result was expected!
the first method was used in a non-compose code and another one in the
compose code.
The PR fixes behavior in a non-compose environment.
- integrate KGP resource API
- packaging final resources to iOS and JS/Wasm applications
- integration tests of publication and multi module support
- info logging of supported Gradle and KGP versions
### requirements
- Kotlin Gradle Plugin >= 2.0.0-Beta05
- Gradle >= 7.6
Fix regression after
https://github.com/JetBrains/compose-multiplatform/pull/4433
`./gradlew compileReleaseKotlinAndroid` in `imageviewer` fails with:
```
* What went wrong:
Execution failed for task ':shared:compileReleaseKotlinAndroid'.
> Inconsistent JVM-target compatibility detected for tasks 'compileReleaseJavaWithJavac' (1.8) and 'compileReleaseKotlinAndroid' (17).
```
(JAVA_HOME points to JDK 17)
Pavel Shishkin
Pavel Shishkin
Konstantin Tskhovrebov
Eliezer Graber
Chanjung Kim
Christian Melchior
xzk
Igor Demin
Igor Demin
Luca Spinazzola
Ivan Matkov