I have no idea how it works on Android, so posting here, but it could be generic problem. In modern ...

# compose-desktop

[orangy]

I have no idea how it works on Android, so posting here, but it could be generic problem.
In modern OSes when you push the button (but don’t release the mouse!), move cursors away from button it gets depressed, and if you release it, no click is registered. All fine here. But, if you don’t release mouse after moving away, and move cursor back into button area, it gets pressed back and if you release the mouse the click is registered. This is not working in Compose (desktop).

[jim]

cc @Chris Sinco [G] for material design expectations.

[Chris Sinco [G]]

From the Material Design POV, there doesn’t seem to be a clear spec for this with buttons.

[Chris Sinco [G]]

When playing with the components on Android (MDC-Android and Compose), it seems the behavior is that if you move your pressed finger away from the button, the pressed state is removed. When moving back, the pressed state does NOT come back, and the touch/tap event is not registered on release over the button.

[Chris Sinco [G]]

However, when playing with Material components that Google uses for Google products on desktop (web), the behavior mentioned is what happens there, which feels expected given it’s a desktop/mouse context.

[Chris Sinco [G]]

More interestingly, iOS actually does this similar behavior with desktop (learned that today), so it seems to be a decision Android made some time ago, and not necessarily Material Design.

[Chris Sinco [G]]

Overall, I would +1 that the behavior @orangy mentioned is what is expected from desktop buttons. However, I’m not technically capable of understanding if it’s something the Compose Android team should address versus Compose Desktop.

[kenkyee]

I think the pressed state on Android was to show the tooltip for the button?
Touch and drag off is what I do sometimes to see what an icon does.

[romainguy]

Tooltips came later

[romainguy]

Not retaining the pressed state makes more sense on a touch screen vs a mouse driven UI

[romainguy]

And this is indeed a behavior from the early days

[romainguy]

There are other things touch specific that Android does and not all of them are present in Compose

[romainguy]

For instance when you press a button, we always keep the pressed state for XXms

[romainguy]

Touch screens are very sensitive and without this enforced duration of the pressed state it can be hard to see that the button went into pressed state

[romainguy]

Compose doesn’t do this yet (@Adam Powell to check me on this)

[Adam Powell]

you're right, it's not there yet

[Adam Powell]

many discussions so far about making some of these behaviors tool-specific, e.g. finger vs. cursor

[jim]

Tracking as https://github.com/JetBrains/compose-jb/issues/567

[zalewski.se]

Quite interesting topic, how would that change on Android if we connect mouse? Will it be cursor or finger kind of experience? 🤔

[TheMrCodes]

To add to it: is there any plans to support 'custem' / further input types for devices like pens?