Slider widget is not reacting to mouse events and sometimes to keyboard events (cursor keys)

[Patrik Svestka]

Slider widget does not correctly react to events.
Grabbing the caret with mouse does work always correctly.

When you want to move the caret with clicking on the caret path it never does work.

With the keyboard it is 50/50 (sometimes it works sometimes it does not) - clicking on the caret and moving it with keys. My guess is that the mouse clicking event on the caret gets ignored and that is why the moving with cursor keys sometimes works sometime not.

I have included a short screencast to show the behavior.

[Patrik Svestka]

Improved method buttonPress:button x:x y:y -> by replacing call pageUp and pageDown; by moveLeft & moveRight. The two methods pageUp & pageDown were deleted.

moveLeft & moveRight are used to move the thumb in correct(named) direction. The two methods call thumbOrigin: for the actual thumb movement.

The calculation of movement is done by subtracting(left) or adding(right) a rangeStep value from/to a model value or if it is missing from/to a virtualModelValue (which is initialized to 0). The method called to decide if model value is present is modelValueCheck:modelValue operation:operator secondValue:secondValue (When a model value present (isNotNil) then it takes precedence before the virtualModelValue)

The step in the Scroller is based on the rangeStep variable (called step in GUI painter). If the rangeStep value is missing a user gets an error message via moveStepMissing call. The user can not continue till rangeStep (step in GUI painter) is filled with valid value. (a reason: there is no meaning in having a slider without step).

[Patrik Svestka]

Fixing thumb movement in the class Scroller

[Jan Vrany]

Replying to patrik.svestka@…:

First of all, thanks a lot for you effort. Second, please, don't take personally my - perhaps harsh - comments:

Improved method buttonPress:button x:x y:y -> by replacing call pageUp and pageDown; by moveLeft & moveRight. The two methods pageUp & pageDown were deleted.

moveLeft & moveRight are used to move the thumb in correct(named) direction. The two methods call thumbOrigin: for the actual thumb movement.

I'd keep original name for two reasons. First, Scroller implements vertical scrollbar so pageUp and pageDown is OK naming. Second, keeping the name would make maintenance (e.g., merging with eXept's code) easier - such rename would confuse most textual diffs (and the auto-merging tools I use now only use textual merge, unfortunately)

The calculation of movement is done by subtracting(left) or adding(right) a rangeStep value from/to a model value or if it is missing from/to a virtualModelValue (which is initialized to 0). The method called to decide if model value is present is modelValueCheck:modelValue operation:operator secondValue:secondValue (When a model value present (isNotNil) then it takes precedence before the virtualModelValue)

The step in the Scroller is based on the rangeStep variable (called step in GUI painter). If the rangeStep value is missing a user gets an error message via moveStepMissing call. The user can not continue till rangeStep (step in GUI painter) is filled with valid value. (a reason: there is no meaning in having a slider without step).

The above looks too compilcated to me. Besides, while most of the functionality is implemented in Scroller, the actual widget
that "does not work correctly" is Slider (resp. HorizontalSlider). Clicking in Scroller (resp. HorizontalScroller) works as expected.

Looking at the code, rangeStep is initialized in Scroller's #initialize method which reads:

    ...
    rangeStart := 0.
    rangeEnd := 100.
    rangeStep := nil.   "/ meaning: arbitrary precision          

So, rangeStep of value apparently has meaning in Scroller.

As you pointed out, when user click into a slider, #pageUp / #pageDown is called. These are overwritten in Slider class, for instance Slider>>pageDown reads:

pageDown
    "ignored - a slider has no concept of page-wise scrolling"

    ^ self 

So, it's not a bug, it's a feature!

Now I do agree that this is confusing, especially as cursor changes it's shape as to suggest that clicking would move the slider io one or another direction. All you need to do is to change Slider>>pageUp and Slider>>pageDown.

See my attempt (attached as issue-85-patch2-Slider-pageUp+pageDown.st). What do you think?

[Patrik Svestka]

Replying to jan vrany:

Replying to patrik.svestka@…:

First of all, thanks a lot for you effort. Second, please, don't take personally my - perhaps harsh - comments:

Don't worry about that. Your comments are spot on.

Improved method buttonPress:button x:x y:y -> by replacing call pageUp and pageDown; by moveLeft & moveRight. The two methods pageUp & pageDown were deleted.

moveLeft & moveRight are used to move the thumb in correct(named) direction. The two methods call thumbOrigin: for the actual thumb movement.

I'd keep original name for two reasons. First, Scroller implements vertical scrollbar so pageUp and pageDown is OK naming. Second, keeping the name would make maintenance (e.g., merging with eXept's code) easier - such rename would confuse most textual diffs (and the auto-merging tools I use now only use textual merge, unfortunately)

I was considering leaving the original pageUp and pageDown. The reason to use moveLeft & moveRight was to improve the understanding of the code. If such rename would confuse the textual diffs you are making then the original names are fine to use; to minimize the effort of manual-merging.

The calculation of movement is done by subtracting(left) or adding(right) a rangeStep value from/to a model value or if it is missing from/to a virtualModelValue (which is initialized to 0). The method called to decide if model value is present is modelValueCheck:modelValue operation:operator secondValue:secondValue (When a model value present (isNotNil) then it takes precedence before the virtualModelValue)

The step in the Scroller is based on the rangeStep variable (called step in GUI painter). If the rangeStep value is missing a user gets an error message via moveStepMissing call. The user can not continue till rangeStep (step in GUI painter) is filled with valid value. (a reason: there is no meaning in having a slider without step).

The above looks too compilcated to me. Besides, while most of the functionality is implemented in Scroller, the actual widget
that "does not work correctly" is Slider (resp. HorizontalSlider). Clicking in Scroller (resp. HorizontalScroller) works as expected.

Looking at the code, rangeStep is initialized in Scroller's #initialize method which reads:

    ...
    rangeStart := 0.
    rangeEnd := 100.
    rangeStep := nil.   "/ meaning: arbitrary precision          

So, rangeStep of value apparently has meaning in Scroller.

As you pointed out, when user click into a slider, #pageUp / #pageDown is called. These are overwritten in Slider class, for instance Slider>>pageDown reads:

pageDown
    "ignored - a slider has no concept of page-wise scrolling"

    ^ self 

So, it's not a bug, it's a feature!

Now I do agree that this is confusing, especially as cursor changes it's shape as to suggest that clicking would move the slider io one or another direction. All you need to do is to change Slider>>pageUp and Slider>>pageDown.

See my attempt (attached as issue-85-patch2-Slider-pageUp+pageDown.st). What do you think?

You are right. I have been solving the issue in the super class but it should have been solved in the child Slider. Your solution is superior because it does not introduce any new instance variables and uses the natural inheritance. I'll try harder next time .]. This is how it should have been in the first place. I'll try to tackle next the issue with the keyboard focus.

[Patrik Svestka]

Could you please add your patch (issue-85-patch2-Slider-pageUp+pageDown.st) to the production branch so it would get included in the newly compiled StX? It solves the issue.