Hi. Is there a way to remove underline of the text (when writing) in BasicTextField? I tried this, b...

# compose

[Roman Polach]

Hi. Is there a way to remove underline of the text (when writing) in BasicTextField? I tried this, but underline is still there:

BasicTextField(
                    singleLine = true,
                    value = text,
                    textStyle = LocalTextStyle.current.copy(textDecoration = TextDecoration.None),
                    readOnly = readOnly,
                    onValueChange = {
                        onValueChanged(it)
                    }
                )

[Chris Sinco [G]]

Are you referring to the bottom outline on the control? Or the text entered itself? Please provide a screenshot for reference

[Roman Polach]

@Chris Sinco [G]: I mean under the text

[Chris Sinco [G]]

TL;DR this is a native UX decision by the platform for the keyboard

https://kotlinlang.slack.com/archives/CJLTWPH7S/p1624322951108000?thread_ts=1624309370.099600&cid=CJLTWPH7S

[Chris Sinco [G]]

Is removing it part of the design / requested by your UX designers?

[Roman Polach]

Yes, it is part of the design. But if there is not easy way to do it, then it is better if i convince them to keep it this way.

[Chris Sinco [G]]

I believe there is not an easy way to do it from the app level. And it would be a bad UX decision regardless to remove it since the underline is a platform level behavior that is expected for all text entry across all apps in Android. I’m not sure if your UX team is reacting to the fact that they don’t see this in iOS, but you can justify it from the UX perspective to say this is what Android users expect in apps, similar to how iOS has it’s own text selection / editing system-level UX.

[chatterInDaSkull]

@Chris Sinco [G] Having an underline doesn’t always make sense - lets say for example i’m entering a hashvalue which only takes in alphanumeric. When one doesn’t have to worry about supporting suggestions and conversions, this works against the ux.

Here’s a very very simple example

ugh.webm

[chatterInDaSkull]

The only way to work around this has been to using

keyboardOptions = KeyboardOptions(
    capitalization = KeyboardCapitalization.None,
    autoCorrect = false,
    keyboardType = KeyboardType.Password,
    imeAction = ImeAction.Next
),

which makes the copied clipboard value being masked (as expected)

[Chris Sinco [G]]

Sure, and those specific cases make sense. Though I’m not sure that is the reason for removing it by the OP.

[chatterInDaSkull]

Fair and maybe worth another thread altogether but this should be supported by the compose code.

https://androidx.tech/artifacts/compose.ui/ui/1.2.0-alpha08-source/androidx/compose/ui/text/input/TextInputServiceAndroid.android.kt.html

Somewhere in this class needs to be a

if (!imeOptions.autoCorrect) {
            this.inputType = this.inputType or InputType.TYPE_TEXT_FLAG_NO_SUGGESTIONS
        }

[Chris Sinco [G]]

cc @Siyamed

[Siyamed]

I thought underline comes from composition but i might be wrong.

We do not have 'suggestions' in the API yet, and should look into it.

KeyboardType.Password might actually be the right option for an example such as hash. (Or an equivalent of do_not_learn since there is no value learning that value for IME)

In terms of UX, how the text editing shows certain signals to user is an important part of platform and user education. Having different behaviors per app might actually confuse users and make editing hard. I suspect there is a balance between per app behavior and OS wide behavior.

[chatterInDaSkull]

I suspect there is a balance between per app behavior and OS wide behavior.

IMO,
• don’t show underscore for suggestions similar to password entry
• don’t have the clipboard show as bullet points (this might be a gboard thing out of your control)