-
Notifications
You must be signed in to change notification settings - Fork 63
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix text input popup position #339
Conversation
Fixes JetBrains/compose-multiplatform#2040 Fixes JetBrains/compose-multiplatform#2493 notifyFocusedRect was deprecated in https://android-review.googlesource.com/c/platform/frameworks/support/+/1959647 On Android, before deprecation this method was used to scroll to the focused text input. This functionality was extracted to the text field itself, but we had another functionality on the other platforms. On Desktop we show text input popup near text input (for some languages): JetBrains/compose-multiplatform#2040 (comment) I think that this method is the right choice to implement this functionality, but I am not completely sure. Here my thoughts about alternatives: 1. Use BringIntoViewRequester. Not sure that it is possible, because its purpose - to show the view to the user, not use the passed information to determine the text popup position 2. Get information about focused area from another source that is not related to text input. For example, we can inject FocusManager, and retrieve the focused rect from it. Probably not a good idea, because the rect of arbitrary focused node isn't the same thing as the rect of focused input area.
|
||
// TODO remove `Deprecated`, if it is removed in AOSP repository | ||
@Suppress("DEPRECATION") | ||
textInputSession.notifyFocusedRect( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Where/how can we observe the focus rect changes? Do we have an API for that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't found such API, but we can write a new one, if we need. Anyway, it seems if we write something like LocalFocusManager.focusedRect
it will be not what we want. We want the rect for text input. And here we can get it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What I mean is that I see a few places which call notifyFocusedRect
, but I don't understand which part actually "observers" the changes so input popup position can be set correctly?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
notifyFocusedRect
subscribed on 2 things:
Modifier.onGloballyPositioned
of the text field, which is called every time its repositioned relative to the window.Modifier.onFocusChanged
which triggers when the focus of text field changes.
I realized, that we don't subscribe on cursor changes. We rely on a side effect of onGloballyPositioned
, which accidentally is called when we change the cursor position (but it seems, it shouldn't). I will investigate, should we also call notifyFocusedRect
somewhere else.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Call it on relayout too now
* PlatformTextInputService. Undeprecate notifyFocusedRect Fixes JetBrains/compose-multiplatform#2040 Fixes JetBrains/compose-multiplatform#2493 notifyFocusedRect was deprecated in https://android-review.googlesource.com/c/platform/frameworks/support/+/1959647 On Android, before deprecation this method was used to scroll to the focused text input. This functionality was extracted to the text field itself, but we had another functionality on the other platforms. On Desktop we show text input popup near text input (for some languages): JetBrains/compose-multiplatform#2040 (comment) I think that this method is the right choice to implement this functionality, but I am not completely sure. Here my thoughts about alternatives: 1. Use BringIntoViewRequester. Not sure that it is possible, because its purpose - to show the view to the user, not use the passed information to determine the text popup position 2. Get information about focused area from another source that is not related to text input. For example, we can inject FocusManager, and retrieve the focused rect from it. Probably not a good idea, because the rect of arbitrary focused node isn't the same thing as the rect of focused input area. * Keep @deprecated until we don't merget this into AOSP
* PlatformTextInputService. Undeprecate notifyFocusedRect Fixes JetBrains/compose-multiplatform#2040 Fixes JetBrains/compose-multiplatform#2493 notifyFocusedRect was deprecated in https://android-review.googlesource.com/c/platform/frameworks/support/+/1959647 On Android, before deprecation this method was used to scroll to the focused text input. This functionality was extracted to the text field itself, but we had another functionality on the other platforms. On Desktop we show text input popup near text input (for some languages): JetBrains/compose-multiplatform#2040 (comment) I think that this method is the right choice to implement this functionality, but I am not completely sure. Here my thoughts about alternatives: 1. Use BringIntoViewRequester. Not sure that it is possible, because its purpose - to show the view to the user, not use the passed information to determine the text popup position 2. Get information about focused area from another source that is not related to text input. For example, we can inject FocusManager, and retrieve the focused rect from it. Probably not a good idea, because the rect of arbitrary focused node isn't the same thing as the rect of focused input area. * Keep @deprecated until we don't merget this into AOSP
* PlatformTextInputService. Undeprecate notifyFocusedRect Fixes JetBrains/compose-multiplatform#2040 Fixes JetBrains/compose-multiplatform#2493 notifyFocusedRect was deprecated in https://android-review.googlesource.com/c/platform/frameworks/support/+/1959647 On Android, before deprecation this method was used to scroll to the focused text input. This functionality was extracted to the text field itself, but we had another functionality on the other platforms. On Desktop we show text input popup near text input (for some languages): JetBrains/compose-multiplatform#2040 (comment) I think that this method is the right choice to implement this functionality, but I am not completely sure. Here my thoughts about alternatives: 1. Use BringIntoViewRequester. Not sure that it is possible, because its purpose - to show the view to the user, not use the passed information to determine the text popup position 2. Get information about focused area from another source that is not related to text input. For example, we can inject FocusManager, and retrieve the focused rect from it. Probably not a good idea, because the rect of arbitrary focused node isn't the same thing as the rect of focused input area. * Keep @deprecated until we don't merget this into AOSP
CL: https://android-review.googlesource.com/c/platform/frameworks/support/+/2319924
the only difference with the CL is that we still keep this method Deprecated, to avoid confusion in the future, if we fix this issue another way.
If this CL will be merged, during rebase most probably will be conflicts. Just drop this commit then.
Fixes JetBrains/compose-multiplatform#2040
Fixes JetBrains/compose-multiplatform#2493
notifyFocusedRect was deprecated in https://android-review.googlesource.com/c/platform/frameworks/support/+/1959647
On Android, before deprecation this method was used to scroll to the focused text input.
This functionality was extracted to the text field itself, but we had another functionality on the other platforms.
On Desktop we show text input popup near text input (for some languages):
JetBrains/compose-multiplatform#2040 (comment)
I think that this method is the right choice to implement this functionality, but I am not completely sure. Here my thoughts about alternatives: