Faculty of Information Technology
Software Engineering Group

Opened 4 years ago

Last modified 3 years ago

#85 new defect

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

Reported by: Patrik Svestka Owned by:
Priority: major Milestone:
Component: default Keywords:
Cc: Also affects CVS HEAD (eXept version): no

Description

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.

Attachments (3)

slider_widget.mp4 (97.1 KB) - added by Patrik Svestka 4 years ago.
Scroller_mouse_event_fixed.st (87.8 KB) - added by Patrik Svestka 3 years ago.
Fixing thumb movement in the class Scroller
issue-85-patch2-Slider-pageUp+pageDown.st (588 bytes) - added by Jan Vrany 3 years ago.

Download all attachments as: .zip

Change History (7)

Changed 4 years ago by Patrik Svestka

Attachment: slider_widget.mp4 added

comment:1 Changed 3 years ago by 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).

Changed 3 years ago by Patrik Svestka

Fixing thumb movement in the class Scroller

comment:2 in reply to:  1 ; Changed 3 years ago by 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?

Changed 3 years ago by Jan Vrany

comment:3 in reply to:  2 Changed 3 years ago by 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.

comment:4 Changed 3 years ago by 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.

Note: See TracTickets for help on using tickets.