Dowgrading to Kotlin 1.8 will allow to use `components` in Kotlin 1.8 and Kotlin 1.9 projects (iOS, JS targets). Now it is supported only in Kotlin 1.9 projects.
* Fix and optimize image animation for 0 and 1 frames
* Change default frame duration to 10fps to match those of a browser
* Fix zero-size image with ImageBitmap.Blank
* Added animated image component
* Simplified network request
* Resource load is now done in the IO Dispatchers
* Renamed constant to express better its use
* Refactored animated image component to use the default Image component instead of creating our own component
* Added missing keys
* Created new module resources & adapted AnimatedImage to it
* Move compose
* Update kotlin version to 1.6.20
* Move compose + Update kotlin version to 1.6.21
* Move compose to include a fix for compose plugin (kjs specific)
Co-authored-by: Oleksandr Karpovich <oleksandr.karpovich@jetbrains.com>
SplitPane by design, shouldn't have default visual representation, because it mostly depends on the design system (material, material3, etc)
Fixes https://github.com/JetBrains/compose-jb/issues/1975
RelNote:
SplitPane no longer depends on compose.material. Now, by default, SplitPane has invisible 0px splitter, not 1px black/white splitter as it was before. If you want to preserve the previous behaviour, specify a splitter explicitly:
```
HorizontalSplitPane(splitterState) {
splitter {
visiblePart {
Box(
Modifier
.height(1.dp)
.fillMaxHeight()
.background(MaterialTheme.colors.background)
)
}
}
}
```
* Fix components script compilation
* Add script to run Gradle with Compose properties set up
It's useful for running a single task in
the included Compose build.
* Set default JVM target to 11 if it is lower
* Update Compose submodule
Using one version of Gradle improves build
performance and dev experience by
reusing Gradle daemons, using less storage
& copying for Gradle cache, etc
* move to kotlin 1.6.10-RC and corresponding compose commit
* Update path to the karma plugin we are patching
* Add ExperimentalComposeWebStyleApi
what worries me that this actually shows that there are some cases where without any changes apart version compiler people will have to worry about such annotations
* update kotlin version in templates to adopt 1.6.10-RC
* web: move ComposableWithNullableTypeParameter.kt to passing test cases
* update kotlin version in other places
* update imageviewer example: add OptIn for experimental API
* move compose
* move to kotlin 1.6.10 and corresponding compose
* move to kotlin 1.6.10 and corresponding compose
* move to 1.0.1-rc2
* move to 1.0.1-rc2 (todoapp)
Co-authored-by: Oleksandr Karpovich <oleksandr.karpovich@jetbrains.com>
Co-authored-by: Shagen Ogandzhanian <shagen.ogandzhanian@jetbrains.com>
Remove:
```
__LATEST_COMPOSE_RELEASE_VERSION__
__KOTLIN_COMPOSE_VERSION__
System.getenv("COMPOSE_TEMPLATE_COMPOSE_VERSION")
```
They pollute templates/examples.
Now, all paths where we need to change the version are hardcoded in the script.
Usage:
```
./replace.sh 1.0.0-rc6
```
This script is planned to run on CI
In the future I will add support for changing Kotlin version
Igor Demin
dima.avdeev
dima.avdeev
Alexander Maryanovsky
Oleksandr Karpovich
Nikita Lipsky
Alexey Tsvetkov
Igor Demin
Verminskiy Vladislav
Ilya Ryzhenkov
Abdelilah El Aissaoui
Igor Demin
Nikolay Igotti
Nikolay Igotti
akurasov