Improve the slider implementation used in range questions

[grzesiek2010]

Closes #7189

Why is this the best possible solution? Were any other approaches considered?

So far, the built-in Compose Slider was responsible for handling all interactions, including dragging, click events, and calculating the current value. This led to some issues, including the one described in the issue, caused by our inability to properly support null values, which forced us to use a workaround.

Adding more hacks or workarounds on top of the existing solution no longer made sense, so I switched to a fully custom slider implementation.

I don’t think this is important enough to justify the risk of including it in v2026.2. Let’s take the time to test it properly and target the v2026.3 release instead.

How does this change affect users? Describe intentional changes to behavior and behavior that could have accidentally been affected by code changes. In other words, what are the regression risks?

The way the slider is rendered and how interactions are handled has changed, so we need to perform full regression testing of this functionality.

Do we need any specific form for testing your changes? If so, please attach one.

Any form with range queston + diffrent parameters.

Does this change require updates to documentation? If so, please file an issue here and include the link below.

No.

Before submitting this PR, please make sure you have:

• added or modified tests for any new or changed behavior
• run ./gradlew connectedAndroidTest (or ./gradlew testLab) and confirmed all checks still pass
• added a comment above any new strings describing it for translators
• added any new strings with date formatting to DateFormatsTest
• verified that any code or assets from external sources are properly credited in comments and/or in the about file.
• verified that any new UI elements use theme colors. UI Components Style guidelines

[seadowg]

Before getting into the code too much, here are a couple of things I'd like to tweak here now we're not under time constraints with this, and we have a completely custom implementation:

1. Can we "flatten" the end edge of the "progress" bar so that it touches the thumb? Currently, it looks awkward rounding off just before:

2. Can we remove the start/end ticks? I think we already have a visual anchor provided by the start/end of the bar itself and the current version just kind of looks accidental:

3. Let's add @Preview functions to make this easier to iterate on in future.

[grzesiek2010]

Can we "flatten" the end edge of the "progress" bar so that it touches the thumb? Currently, it looks awkward rounding off just before:

Done.

Let's add @Preview functions to make this easier to iterate on in future.

Done.

Can we remove the start/end ticks? I think we already have a visual anchor provided by the start/end of the bar itself and the current version just kind of looks accidental:

The current implementation aligns with how the built-in one looks. See: https://m3.material.io/components/sliders/specs#anatomy, so I don't think we should remove it.

[seadowg]

The current implementation aligns with how the built-in one looks. See: https://m3.material.io/components/sliders/specs#anatomy, so I don't think we should remove it.

Not quite:

The Material examples have much larger padding on the extreme end which makes it look more intentional. That said, I don't think I've ever actually seen the ticks used like this in the Android system apps: if there's that much padding it doesn't really make sense as the last tick! I'm not sure what's going on there. I'd still vote for just ditching them and keeping the intermediate ones.

This might be a good thing to get an opinion from @nicoleorlowski on.

[seadowg]

#7216 (comment)

[nicoleorlowski]

Removing looks better to me!

…

On Thu, May 14, 2026, 1:53 a.m. Callum Stott ***@***.***> wrote: *seadowg* left a comment (getodk/collect#7216) <#7216 (comment)> The current implementation aligns with how the built-in one looks. See: https://m3.material.io/components/sliders/specs#anatomy, so I don't think we should remove it. Not quite: Screenshot.2026-05-14.at.09.48.25.png (view on web) <https://github.com/user-attachments/assets/6ff7cdb6-13f0-40a2-b843-fe1ae776f701> The Material examples have much larger padding on the extreme end which makes it look more intentional. That said, I don't think I've ever actually seen the ticks used like this in the Android system apps: if there's that much padding it doesn't really make sense as the last tick! I'm not sure what's going on there. I'd still vote for just ditching them and keeping the intermediate ones. This might be a good thing to get an opinion from @nicoleorlowski <https://github.com/nicoleorlowski> on. — Reply to this email directly, view it on GitHub <#7216 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHHYSK3LJG33C5OOVAP3YRL42WCQZAVCNFSM6AAAAACYQWOFKCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DINBZGE3TGNBRGA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[seadowg]

This is looking awesome! One last tweak I want to discuss: I'm noticing that trying to slide the thumb when it's at either end is hard as we're within the back gesture zones. I'm wondering if we should add system gesture inset padding here? It definitely doesn't look as good, but it does make it easier to use.

[grzesiek2010]

This is looking awesome! One last tweak I want to discuss: I'm noticing that trying to slide the thumb when it's at either end is hard as we're within the back gesture zones. I'm wondering if we should add system gesture inset padding here? It definitely doesn't look as good, but it does make it easier to use.

Instead of adding padding (which would change the look), I've used systemGestureExclusion on the slider track. This tells the system that this specific area should handle touch events itself, even if it's within the system gesture zones. This way, we keep the edge-to-edge look while making it easy to grab the thumb at the ends.

[seadowg]

Digging into the different slider implementations, there's a lot of duplicated code and constants (sizes, margins etc.). I'm thinking we might want more shared Composables with an "orientation" arg that does things like switch which dimension goes on width vs height. Another trick might be to extract shared modifier extensions.

[grzesiek2010]

Digging into the different slider implementations, there's a lot of duplicated code and constants (sizes, margins etc.). I'm thinking we might want more shared Composables with an "orientation" arg that does things like switch which dimension goes on width vs height. Another trick might be to extract shared modifier extensions.

Done.