IssueTracker

Do you have some sample code you could share that reproduces the issue?

Here's a sample code

https://gist.github.com/dovahkiin98/95157e662daacddfbc1b60e0fb8bb7c0

setContent {
    MaterialTheme {
        LongClickButton()
    }
}

Neither the Button nor the IconButton can take the combinedClickable Modifier. Probably because combinedClickable is not stackable

Thanks for filing this.

We don't have any plans to support click-based modifiers on the components that already handle clicks or other touch gestures.

Button in material can be only clickable, that's the intent and design decision we've made. For example, it is hard for users to discover that long click is something that is available on the button.

If, for one's UX reasons, they need to have a long/double clickable, they need to create their own Button using the version of surface with no click + click modifiers.

But many applications allow users to long click on a Card or ListTile to select it or start selection, or show an options menu with available actions on the item

It seems like in this case you need to have your own Card or ListItem.

Because if you want to start a selection, the proper choice would be to have a Modifier.selectable or Modifier.toggleable involved as well, or many a more sophisticated combination of long click + toggleable. Modifier.toggleable or Modifier.selectable (depending on your needs) provide proper accessibility semantics to users so please consider using those.

And the above is the one more reason why we don't allow for an easy integration between long click + clickable card :)

So it's intended that we should try to duplicate the implementation of, say, IconButton, while not actually having access to things like modifier.minimumTouchTargetSize()?

For cases like tooltips and such, there's been a number of requests to do this. If you want your own custom onLongClick - please make your own IconButton, that's intended.

As for minimumTouchTargetSize - this is interesting, seems like we dan think about opening it to everyone so that they can make proper components. Louis, what do you think?

The same is true of RippleRadius. In the end, if I want a TextField to have a trailing icon for backspace functionality (like the default dialer does), and I want it to be long-clickable to clear the TextField (also like the default dialer does), I need to do something like:

fun IconButton(
    onClick: () -> Unit,
    onLongClick: () -> Unit,
    content: @Composable BoxScope.() -> Unit
) {
    Box(
        contentAlignment = Alignment.Center,
        modifier = Modifier
            .size(48.dp)
            .combinedClickable(
                role = Role.Button,
                interactionSource = remember { MutableInteractionSource() },
                indication = rememberRipple(bounded = false, radius = 24.dp),
                onClick = onClick,
                onLongClick = onLongClick
            ),
        content = content
    )
}

For this, I needed to inspect the implementation of compose.IconButton. Then I need to inspect minimumTouchTargetSize(), which seems to be 48.dp (according to code comments). However, setting it to 48.dp is naive, as minimumTouchTargetSize() does more than set the size. There's also a potential accessibility miss where I don't realize I should assign Role.Button, but maybe that's on me. Finally, there's RippleRadius, which is hardcoded to 24.dp. That's not too bad, but it decouples us from material's value for whatever that is, should it change in the future.

Sounds reasonable to expose minimumTouchTargetSize() for this case, yes. Might also be reasonable to expose the ripple radius - which is usually 24.dp for all unbounded components (icon button / checkbox / switch / radio button / slider thumb) in M2.