Adopt PlatformTextInputService2#2990
Conversation
0a329e6 to
48793e2
Compare
9f5fc0a to
1f0c16d
Compare
…vice2 # Conflicts: # compose/ui/ui/src/iosMain/kotlin/androidx/compose/ui/platform/IOSSkikoInput.ios.kt # compose/ui/ui/src/iosMain/kotlin/androidx/compose/ui/platform/UIKitTextInputService.ios.kt # compose/ui/ui/src/iosMain/kotlin/androidx/compose/ui/scene/ComposeSceneMediator.ios.kt # compose/ui/ui/src/iosMain/kotlin/androidx/compose/ui/window/NativeTextInputView.ios.kt # compose/ui/ui/src/uikitInstrumentedTest/kotlin/androidx/compose/ui/leaks/MemoryLeaksTest.kt
| newCursor + newCursorPosition - text.length | ||
| } | ||
| buffer.setSelectionCoerced(newCursorInBuffer, newCursorInBuffer) | ||
| setSelection(newCursorInBuffer, newCursorInBuffer) |
There was a problem hiding this comment.
I was against this change, but not a blocker, I guess.
There was a problem hiding this comment.
Vendula Švastalová (@svastven) , please take a look here
There was a problem hiding this comment.
To me, current state reads better, that's why I gave the suggestion. Should setSelection implementation change later, then setSelection is probably no longer the best name for the function (?). Willl leave the decision up to you Andrei Salavei (@ASalavei)
There was a problem hiding this comment.
This is the question of style only.
My take here: both, setSelection and setComposingRegion use only one function call inside which I think does not bring any additional value and does not improve clarity. I would rather remove these functions and use buffer directly.
Vendula Švastalová (@svastven) , Alexander Maryanovsky (@m-sasha) ?
There was a problem hiding this comment.
Sounds good to me
There was a problem hiding this comment.
I would rather remove these functions and use buffer directly.
Do you mean remove the calls/delegation to these functions? Because I don't think you can remove the functions themselves...
There was a problem hiding this comment.
Ah, sorry - missed that fact. Have to change the reasoning then, it's not a matter of style anymore.
At the main workflow, the functions commitText and setComposingText modify the buffer. It means, all calls preferably should go to the buffer to improve readability and keep the function code solid.
There was a problem hiding this comment.
This already exists in LegacyPlatformTextInputServiceAdapter.skiko.kt.
Would it not be better to reuse it, or at least parts of it?
There was a problem hiding this comment.
Alexander Maryanovsky (@m-sasha) , it cannot be the LegacyPlatformTextInputServiceAdapter due to the implementation specifics. Most likely it should be a new class exposed from the "ui-text". My ides was to avoid that. WDYT?
…vice2 # Conflicts: # compose/ui/ui/src/iosMain/kotlin/androidx/compose/ui/text/input/ComposeTextInputConnection.ios.kt
Extend the functionality of the
TextEditingScopeand adjust its behaviour to align with theEditProcessor's commands.Apply
recomposeAndLayoutafter edit commands to recalculate the text and layout state.Refactor the
UIKitTextInputServiceto use thePlatformTextInputMethodRequestdirectly to bypass issues caused by delays in mutable state propagation.Add the
UIKitTextInputServiceAdapterto support the deprecatedPlatformTextInputService.Fixes https://youtrack.jetbrains.com/issue/CMP-7832/iOS-Adopt-PlatformTextInputService2
Fixes https://youtrack.jetbrains.com/issue/CMP-7983/BasicTextFieldTextFieldState-inputTransformation-reports-inconsistent-changes-between-Android-and-iOS
Fixes https://youtrack.jetbrains.com/issue/CMP-9566/BasicTextField-w-InputTransformation-incorrect-internal-state-on-iOS
Release Notes
Fixes - iOS
BasicTextFieldreported inconsistent changes between Android and iOSBasicTextFieldwithInputTransformationmay use the incorrect internal text state.