This is related to issue:
https://github.com/JetBrains/compose-multiplatform/issues/4258
changes
- DesktopSplitPane.kt: placable.place() -> placable.placeRelative
- SplitePaneDSL.kt: change the delta direction to follow the layout
direction
```kotlin
@Composable
override fun Modifier.markAsHandle(): Modifier = this.run {
val layoutDirection = LocalLayoutDirection.current
pointerInput(containerScope.splitPaneState) {
detectDragGestures { change, _ ->
change.consume()
containerScope.splitPaneState.dispatchRawMovement(
if (containerScope.isHorizontal)
if (layoutDirection == LayoutDirection.Ltr) change.position.x else -change.position.x
else change.position.y
)
}
}
```
the problem with .onPointerEvent() Modifier, or onDrag also, is
whenever the layout direction is Ltr or Rtl:
moving to right always produce positive change, [expected negative if
dir =Rtl]
moving to left always produce negative change, [expected positive if dir
=Rtl]
the calculation of postion will fail if layoutDir is Rtl, because
positionPercentage will be out of range
```kotlin
fun dispatchRawMovement(delta: Float) {
val movableArea = maxPosition - minPosition
if (movableArea > 0) {
positionPercentage =
((movableArea * positionPercentage) + delta).coerceIn(0f, movableArea) / movableArea
}
}
```
Introduced a function to process and replace certain escaped symbols
like '\n', '\t', and '\uXXXX' in the strings extracted from compose
string resources.
Update kotlin and dependencies and add verification-metadata.xml file to
verify vlcj artifacts
---------
Co-authored-by: Igor Demin <igor.demin@jetbrains.com>
The recent compose core libs are built using 1.9.21, and apparently, older k/native versions don't support them.
e: kotlin.NotImplementedError: Generation of stubs for class org.jetbrains.kotlin.ir.symbols.impl.IrTypeParameterPublicSymbolImpl is not supported yet
Motivation: sometimes we push minor commits without a PR, but anyway sometimes they break the tests (or make something incompatible. e.g. versions update)
See https://github.com/caprica/vlcj/tree/vlcj-4.x#threading-model
# Threading Model
This section is very important.
With vlcj-4, every native event coming from LibVLC is processed on the
native callback thread. This should give some small performance gains
when compared with vlcj-3.
The critical issue is that it is generally not permitted to call back
into LibVLC from the event callback thread. Doing so may cause subtle
failures or outright hard JVM crashes.
A prime example of the sort of trap waiting for you is the very common
case of handling a media player "finished" event so that you can then
play the next item in a play-list:
```java
mediaPlayer.events().addMediaPlayerEventListener(new MediaPlayerEventAdapter() {
@Override
public void finished(MediaPlayer mediaPlayer) {
mediaPlayer.media().play(nextMrl); // <-- This is VERY BAD INDEED
}
});
```
In this example, the finished method is being invoked on a native
callback thread owned by LibVLC. The implementation of this method is
calling back into LibVLC when it invokes play. This is very likely to
cause a JVM crash and kill your application.
In cases such as this, you should make use of an asynchronous
task-executor queue conveniently provided by the MediaPlayer object
passed to the listener method:
```java
mediaPlayer.events().addMediaPlayerEventListener(new MediaPlayerEventAdapter() {
@Override
public void finished(final MediaPlayer mediaPlayer) {
mediaPlayer.submit(new Runnable() {
@Override
public void run() {
mediaPlayer.media().play(nextMrl);
}
});
}
});
```
Konstantin Tskhovrebov
Shishkin Pavel
Ahmed Hosny
Igor Demin
Oleksandr Karpovich
antonindrawan
InsanusMokrassar
dima.avdeev
Alexander Maryanovsky
AmirHossein Abdolmotallebi
hehua2008