Scroll speed configuration suggestions
All of the following is only a proposal :)
Now that !4508 (merged) is merged, my next goal is to implement scroll speed settings in
gnome-control-center for Wayland. I imagine 1 setting for each Wayland scroll source type:
|Setting name in GNOME control center||
|Mouse scroll speed||
|Touchpad scroll speed||
|Trackpoint/continuous device scroll speed||
I don't want such settings sip into
GdkScrollEvent deltas magnitude because these settings only address scrollable views.
An example with the mouse wheel : I play a FPS where I can change my weapon just by making a single wheel click up or down. If I change the "Mouse scroll speed" in the control center, I don't want this setting to have an influence on the video-game behavior. Imagine having to make 5 wheel clicks instead of 1 to change the weapon of not be able to iterate through weapons 1 by 1 but only 3 per 3 because of a non-default scroll speed...
That's why it's only the final widget that should choose to take in consideration the "Scroll speed settings" or not. Our video game will choose to do not but a giant scrollable web view in a web browser will choose to do. GDK must report RAW deltas in all circunstances IMHO.
This is exactly the same thing as
SPI_GETWHEELSCROLLLINES in Windows but with 1 setting per scroll "source".
The 3 settings are stored in dconf (gsettings) and are accessible through 3 new GDK functions:
If a GDK client is managing a scrollable view or a widget that is legitimately concerned by the "Scroll speed" user-parameters, he should call the relevant function depending on the "scroll source", and multiply the
GdkScrollEvent deltas per the returned factor to obtain the number of screen "pixels" to directly scroll. The client can also choose to adapt a bit this "native" experience depending on the case (exemple: really really small scrollable widgets like comboboxes with mice will probably need a reduced speed in any case). But here comes the problem.
GdkScrollUnit API exposes the scroll unit like this:
|Wayland scroll source||
As you can see, the client can't see the difference between
continuous events on wayland, so he can't make the difference between touchpads and trackpoints events so he doesn't know if he have to call
gdk_get_continuous_scroll_speed() to provide the good consistent "scroll speed".
It's hard to write that but I think
gdk_scroll_event_get_unit() should be renamed to
gdk_scroll_event_get_source() and provide 3
For the migration: every
GDK_SCROLL_UNIT_WHEEL uses are replaced by
GDK_SCROLL_SOURCE_WHEEL, pretty simple. It's more complicated for
GDK_SCROLL_UNIT_SURFACE: should macos events with this unit be replaced per
GDK_SCROLL_SOURCE_CONTINUOUS? I don't really know. On Wayland, a
finger event will result in
GDK_SCROLL_SOURCE_FINGER and a
continuous event will result in
The scroll source continues to be linked to the scroll deltas unit:
GDK_SCROLL_SOURCE_WHEEL is still in wheel detent clicks and
GDK_SCROLL_SOURCE_CONTINUOUS are in screen surface coordinates.
I dare to propose all that stuff just after the !4508 (merged) merge because this new API is for GNOME 43 which will be released in a long time so I said to myself it was worth a try. I would like to have feedbacks about this before going into the GTK 3 backport if possible. These suggestions will not make the default touchpad and trackpoint scroll speed break again unlike !4508 (merged).
Thanks for your feedbacks.