Community
Participate
Working Groups
On Linux adding a MouseWheel event to a Composite and using a Notebook's touchpad might result in events with event.count == 0.
Created attachment 287747 [details] Snippet
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/189229
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/189241
Explanation: until now a scrollevent only happend if the double value reported by GTK was > 0.333. I reckon, that way slow scroll events from some mousepads simply were ignored. Now the double values are accumulated and if the sum gets large (absolute) enough, an event is sent. The user who reported this problem is happy now.
(In reply to Thomas Singer from comment #4) > Explanation: until now a scrollevent only happend if the double value > reported by GTK was > 0.333. I reckon, that way slow scroll events from some > mousepads simply were ignored. Now the double values are accumulated and if > the sum gets large (absolute) enough, an event is sent. The user who > reported this problem is happy now. Two things: 1) why was user unhappy with events count == 0? Any errors? Wrong UI behavior? 2) Please add a better commit message explaining the change (like you did it above), amend & rebase & push the commit
Problem: the scrolling did not work smooth enough. I then noticed that sending scroll events without a scroll amount is useless. I'll update the patch later.
Answering your comment: some mouse pads seem to deliver only small amounts of scrolling. In other controls, e.g. Table, Tree, this causes smooth slow scrolling. If you try to implement an own component (see snippet), however, such slow scrolling was simply ignored and became "jumpy". If you don't want to have the 2 double variables in all Controls, do you think it might be useful to move the whole method to Composite? But then incorrect code would remain in Control.
Is the last patch acceptable now?
I did an analysis of how native GTK applications handle scrolling, and my findings are: 1) Contrary to my expectations, using a non-smooth mouse wheel still produces smooth scrolling events in 'Control.gtk_scroll_event()': false = gdk_event_get_scroll_direction() true = gdk_event_get_scroll_deltas() +1/-1 = delta_y 2) Synaptics touchpad produces smooth scrolling events on my Ubuntu 21.04 It sends events with 'delta_y' containing all kinds of values. 3) GTK scrolls the following number of pixels per each unit of 'delta_y' : pixels = pow(control_height, 2.0/3.0) See 'get_scroll_unit()' called from 'gtk_scrolled_window_scroll_event()' Now what does SWT's 'event.count' even mean? 4) SWT-GTK implementation sends 'SWT.SCROLL_LINE' with value (3*delta_y) 5) 3x multiplier is first seen in Bug 7101 for directional scrolling Bug 7101 adds support for both Windows and GTK. On Windows, 'SPI_GETWHEELSCROLLLINES' is used to query the multiplier. It equals 3 by default. I understand that same multiplier was used in GTK to have similar behavior. 6) Bug 393793 adds smooth scrolling, also with 3x multiplier I understand that 3x is used to match existing code for directional scrolling. 7) Summary: value of 'event.count' matches that on Windows However, on Windows, every unit of 'event.count' scrolls one row (line of text, row of Table, etc), and on GTK, it scrolls pixels and distance depends on Control's height. It's up to SWT application to decide whether to have same behavior cross-platform or to follow platform's rules for scrolling. If Windows style behavior is desirable, scroll one row per 'event.count'. If GTK style behavior is desirable, use formula from (3).
(In reply to Alexandr Miloslavskiy from comment #9) > I did an analysis of how native GTK applications handle scrolling, and my > findings are: > 1) Contrary to my expectations, using a non-smooth mouse wheel still > produces smooth scrolling events in 'Control.gtk_scroll_event()': > false = gdk_event_get_scroll_direction() > true = gdk_event_get_scroll_deltas() > +1/-1 = delta_y > 2) Synaptics touchpad produces smooth scrolling events on my Ubuntu 21.04 > It sends events with 'delta_y' containing all kinds of values. > 3) GTK scrolls the following number of pixels per each unit of 'delta_y' : > pixels = pow(control_height, 2.0/3.0) > See 'get_scroll_unit()' called from 'gtk_scrolled_window_scroll_event()' > > Now what does SWT's 'event.count' even mean? > 4) SWT-GTK implementation sends 'SWT.SCROLL_LINE' with value (3*delta_y) > 5) 3x multiplier is first seen in Bug 7101 for directional scrolling > Bug 7101 adds support for both Windows and GTK. > On Windows, 'SPI_GETWHEELSCROLLLINES' is used to query the > multiplier. It equals 3 by default. I understand that same > multiplier was used in GTK to have similar behavior. > 6) Bug 393793 adds smooth scrolling, also with 3x multiplier > I understand that 3x is used to match existing code for directional > scrolling. > 7) Summary: value of 'event.count' matches that on Windows > However, on Windows, every unit of 'event.count' scrolls one row > (line of text, row of Table, etc), and on GTK, it scrolls pixels > and distance depends on Control's height. It's up to SWT application > to decide whether to have same behavior cross-platform or to follow > platform's rules for scrolling. > > If Windows style behavior is desirable, scroll one row per 'event.count'. > If GTK style behavior is desirable, use formula from (3). System default scrolling should be the preferred one IMHO. Having two apps scroll direrently on same machine is terrible user experience. By the numbe of the bugs you refer to - this must have been gtk 1.x time so it's behavior has been quite different or even not yet well defined.
