Anyone have any suggestions for this? My design re...
# compose-android
b
Anyone have any suggestions for this? My design requires that I have a label that is visible when a text field is not focused, but is not shown when it is focused. I don't have any problems hiding or showing the icon within the trailingIcon composable that a BasicTextField takes, but I am running into some less than ideal behavior when leaving the textfield while it's scrolled to the end. not kotlin but kotlin colored See đź§µ
Here's the textfield when its position is at the end and focused.
here's what it looks like after I leave the textfield. As you can see, I leave the textfield at the end, but then the duplicate label shrinks the size of the innerTextField() but then isn't scrolled at the end anymore.
I've tried setting the textFieldValue selection to TextRange(textFieldValue.text.length) onFocusLost, which seems to only work if my cursor position isn't already at the end.
cursor position not changing when already at the end.webm
z
Might need to be able to explicitly control scroll state to make this work. Not supported in current BTF, but will be in BTF2
b
I see. Seems like even more reason to push back on this design. Any suggestions for how to ideally handle this? Am I going about something the wrong way? The initial design had the Duplicate label right up next to the text in the innerTextField() which was really difficult to work with and not have the duplicate label clip behind the committed label when the text was long. Personally I've tried to push design to go towards a native Material 3 TextField which has a filled TextField with a floating label + supporting text, and then still using the trailingIcon for the Committed pill label, though those still do pop in and out based on whether the text matches a committed item.
z
b
I don't think it's that issue, I don't have any problems with the keyboard, just with the scroll position of the textfield when the innerTextField is resized.
z
Right but it’s probably the same underlying bug
But to your question, I don’t know if there’s a good way to implement this with the current BTF. Sorry i don’t have a better answer
b
and the "TextField" is just a material implementation using BasicTextField, right? So even less flexible in terms of possibly supporting this design?
z
and the “TextField” is just a material implementation using BasicTextField, right
yes
So even less flexible in terms of possibly supporting this design
Theoretically, although moot in this case since BTF doesn’t support it either. The material wrappers for BTF2 will let you hoist scroll state as well though.
b
Cool, I've never even seen that pop up in my suggestions when typing BasicTextField, yet here it is. Seems like an experimental API. We're already using 1.6.0-beta03, because our LazyColumns crash with only internal code being referenced in the stack trace when on 1.5.3. I think that has to do with a combo between 1.5.3 and Material 3 Alpha though. Material 3 Alpha seems to have a problem with not being able to present the ime on a focused TextField. Do you know if that's already an issue tracked?
no ime presenting .webm
z
That bug is fixed in BTF on main. It might be that the last release of M3 alpha was not depending on the compose foundation version that fixed it?
b
I see. I have "compose_ui_version = '1.6.0-beta03'" in my buildscript, but it looks like compose foundation is set to 1.5.4. if Material 3 Alpha relies on a specific foundation version like 1.6.0 Alpha though, it will use that instead of what I have specified, right?
ah, looks like going to the latest alpha on the compose foundation as well fixed it, it must have been using a min requirement of like 1.6.0 alpha 1 or something which hadn't had the BTF fix from Main in it.
z
sorry my bad, the fix was in ui, not foundation
b
oh, that's weird? I'm not sure why incrementing the Foundation to alpha03 from 1.5.3 fixed it for me. Not sure what's going on.
z
i didn’t think that bug was in 1.5.3… idk, maybe something weird was happening with version resolution
b
Do you know if there's issues with the drag handle not scrolling a text field all the way? I've always been under the impression that with a drag handle I should be able to scroll a textfield from start to finish, seems like I have to scroll the textField independently because the drag handle won't get me all the way to the beginning with Compose.
Screen_Recording_20231218_125045_Banko.mp4
z
i think a bug around that was fixed recently too. you’re seeing this on the latest alpha?
b
Yeah, I'm on the latest material3 alpha and compose UI and foundation alpha
Material3 beta03 I mean