Number Slider Behaviour with incorrectly set Markers

[zeitlings]

Alfred 5.5 [2257]

macOS 14.4.1 (23E224)

 

When scaling from low to high, the slider is one number shy.

https://imgur.com/a/QkfEdRE

 

[vitor]

Could you share the workflow? So we can properly look at the config and replicate live to see what’s happening?

[zeitlings]

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.

 

[zeitlings]

Another problematic configuration with the same problem (that needs a different solution):

 

 

 

[Andrew]

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.

[Andrew]

@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.

[zeitlings]

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.