P4
Currently, javafx.scene.control.Slider generates major tick marks by implicitly anchoring the lattice at the slider’s min value. This behavior produces awkward or semantically meaningless tick positions whenever min is not a “nice multiple” of majorTickUnit.
=== Expected behavior:
- majorTickUnit should define the spacing between ticks, independent of min value.
- The lattice of ticks should start at multiples of majorTickUnit (from 0 by default).
- Only ticks within [min, max] are displayed.
=== Examples:
1. Linear slider:
min = 1, max = 20, majorTickUnit = 10
Current: 1, 11, 20 (clipped)
Expected: 1 (clipped), 10, 20
2. Shifted/clipped range:
min = -0.9, max = 1.9, majorTickUnit = 1
Current: -0.9, 0.1, 1.1, 1.9 (clipped)
Expected: -0.9 (clipped), 0, 1, 1.9 (clipped)
=== Rationale:
Treating majorTickUnit as a spacing/multiple rather than “distance from min” aligns with developer expectations. The current behavior is rarely useful; most real-world sliders intend for ticks to align with multiples of the major tick unit. Fixing this improves semantic consistency without introducing new API.
=== Optional / future extension:
For advanced cases, a numeric tick offset or explicit tick collection could allow full control over tick placement. This is common in other UI toolkits for cases where ticks are not evenly distributed (ie. ticks at every prime number while the slider remains linear).
Most linear and near-linear sliders would be fully resolved by this bug fix alone.
=== Proposed fix:
Compute the major tick lattice as multiples of majorTickUnit starting from 0 (or nearest multiple), truncating ticks outside [min, max].
Remove the implicit anchoring at min.
=== Backward Compatibility Considerations:
- The current behavior of anchoring majorTickUnit at min is unlikely to ever be intentionally relied upon, because in most cases min is not a “nice multiple” of the tick unit.
- Existing sliders often produce awkward intermediate ticks (e.g., 1, 11, 20), which are semantically meaningless. Fixing the lattice to multiples of majorTickUnit improves predictability.
- For sliders where min is already a multiple of majorTickUnit, the lattice is unchanged — behavior remains identical.
- Ticks outside [min, max] are still clipped as before, preserving domain boundaries.
- Optional future extensions (numeric offset or explicit tick collection) can restore any edge-case behavior if needed.
=== Expected behavior:
- majorTickUnit should define the spacing between ticks, independent of min value.
- The lattice of ticks should start at multiples of majorTickUnit (from 0 by default).
- Only ticks within [min, max] are displayed.
=== Examples:
1. Linear slider:
min = 1, max = 20, majorTickUnit = 10
Current: 1, 11, 20 (clipped)
Expected: 1 (clipped), 10, 20
2. Shifted/clipped range:
min = -0.9, max = 1.9, majorTickUnit = 1
Current: -0.9, 0.1, 1.1, 1.9 (clipped)
Expected: -0.9 (clipped), 0, 1, 1.9 (clipped)
=== Rationale:
Treating majorTickUnit as a spacing/multiple rather than “distance from min” aligns with developer expectations. The current behavior is rarely useful; most real-world sliders intend for ticks to align with multiples of the major tick unit. Fixing this improves semantic consistency without introducing new API.
=== Optional / future extension:
For advanced cases, a numeric tick offset or explicit tick collection could allow full control over tick placement. This is common in other UI toolkits for cases where ticks are not evenly distributed (ie. ticks at every prime number while the slider remains linear).
Most linear and near-linear sliders would be fully resolved by this bug fix alone.
=== Proposed fix:
Compute the major tick lattice as multiples of majorTickUnit starting from 0 (or nearest multiple), truncating ticks outside [min, max].
Remove the implicit anchoring at min.
=== Backward Compatibility Considerations:
- The current behavior of anchoring majorTickUnit at min is unlikely to ever be intentionally relied upon, because in most cases min is not a “nice multiple” of the tick unit.
- Existing sliders often produce awkward intermediate ticks (e.g., 1, 11, 20), which are semantically meaningless. Fixing the lattice to multiples of majorTickUnit improves predictability.
- For sliders where min is already a multiple of majorTickUnit, the lattice is unchanged — behavior remains identical.
- Ticks outside [min, max] are still clipped as before, preserving domain boundaries.
- Optional future extensions (numeric offset or explicit tick collection) can restore any edge-case behavior if needed.