DirectSlider: Changing visible travel range

Scripting Issues
1

Hello all!

We’re continuing to work with DirectSliders; we ran into another issue we’re trying to resolve.

By default, it appears that the DirectSlider operates such that the slider is contained inside the track, like a scrollbar. That is to say, the maximum travel is

[]
------------

          []
------------

This is great for scroll-bar-like behavior (as scroll bars are bounded on either side). But for a slider-like behavior, we really want more of this sort of operation:

\/
 ---------

         \/
 ---------

That is, the slider should hang off the end of the bar, with one half of it exceeding the bar length.

Another way to say this is that if we were to replace the slider thumb’s default visual representation (a rectangle) with an inverted triangle, then when slider[‘value’]==slider[‘range’][0], the bottom point of the triangle would be aligned with the left edge of the slider. The default behavior is that the top-left point of the triangle is aligned with the left edge of the slider.

We have a partial solution to this problem, which is to set [‘thumb_frameSize’] to (0,0,0,0). This solves the positioning problem, but makes it impossible to actually click on the thumb (since the clickable region is the frame). Is there a way to control the bounding behavior so that we can keep the framesize nonzero but allow the center of the slider thumb to align with the edge of the slider bar?

Thanks,
Mark

2

Hmm. How about if you shortened the visible representation of the trough, by the width of half the thumb on each end, while keeping its actual frame size the same?

In order to do this, you would have to create a custom geometry for the trough, and use relief = None (rather than letting it create a default trough for you). But it would be easy to do this using, for instance, the CardMaker.

This is, of course, just another hack. :slight_smile: We should really fix the underlying implementation to support this concept directly. I’ll put it on the list.

David

3

Ah, a simpler variant on the above hack just occurred to me: compute the frameVisibleScale such that its visible length is just the right amount (one thumb’s width) shorter than its actual length.

David