Jump to content

Number Slider Behaviour with incorrectly set Markers

Recommended Posts

Of course, but I think I already located the problem, which is partly due to a lapse on my side: 




A solution could be that when "Only Stop on Markers" is checked, the amount of markers to show defaults to the count of indices in the specified closed range (Min...Max). I.e. I should have entered 10 instead of 9, but to only have 9 markers where 10 are required to cover the range makes little sense. Going from 8 to 9 in this scenario also jumps to 10 immediately (which persists) skipping 9, but going back to 8 falls back on 7 after saving.


Link to comment

This is actually a pretty interesting quirk, and it looks like Alfred's doing everything he can correctly. In the first example, Alfred is correctly saving the visible integer value, and when re-opening is setting that same value back on to the macOS slider, but the macOS slider component is truncating and snapping it to the lower value (closer marker).


I already mention in the subtext for the Only Stop on Markers: "Test your configuration carefully to match your desired value range", which is essentially warning about what you've found.


I could update this to show a warning that the markers don't divide cleanly into the number range, I'll add an internal ticket to have a think about it.

Link to comment
  • Andrew changed the title to Number Slider Behaviour with incorrectly set Markers

@zeitlings I've put in some range and divisor warnings for the next build, and upped the artificial 25 maximum markers limit.


As a side note, after spending some time fiddling with this, setting the snapped marker count incorrectly is an easy (non-obvious) trap to fall into, so the additional warnings are very useful. Thanks for highlighting this issue.

Link to comment
54 minutes ago, Andrew said:

setting the snapped marker count incorrectly is an easy (non-obvious) trap to fall into


That's what I was thinking. Additional warnings that kick in dynamically when something is off will be helpful (similar to what happens when a required variable is not set in the user-facing workflow configuration), and is probably better than silently adjusting the configuration to a setting that works. I can see this causing irritation as well.

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Create New...