I wanted to enable steppers for use in a touch-centric application.
I noticed however, that apparently steppers have been removed in GTK4?
Are steppers still planned to be added back to GTK at some point, or will it be the user’s responsibility to implement them?
Steppers have long since been removed by default: scroll bars act as an indicator of the position inside a content area. For fine control, you can long press the scroll bar (which will grow in size on hover), or use Shift + pointer click.
See: A scrolling primer – GTK Development Blog
No, they are not coming back.
The scrollbars were introduced by Xerox in the 1970s. The arrow buttons were added sometime later (by Apple?) and then were considered as an improvement. Nowadays, the removing arrow buttons is considered as an improvement. In the DOS-applications with a character-based fullscreen user interface the “scrollbars” were used for most part simply as indicators. However, the reason was the lack of or only limited mouse support.
What does it remind you of? The fashion industry! The set of ideas is limited and you need to organize a rotation of them (In this season…). BTW, I can’t remember any large improvements in the GUI design made in the 21st century.
Here (Scrollbar History - UI design is difficult - Mac History) you have the description, how the scrollbar worked in an Apple application of that time and in a Xerox application. The GTK4 approach is more similar to the Xerox approach (and less intuitive, IMHO).
If you actually read the blog post(s) they say the steppers were removed because the click targets are too small. That causes accessibility issues.
And if we are talking about “fashion” then technically all computers are a fashion, after all people used to be fine with just using typewriters.
“accessibility issues” for whom? For everyone, for most users, for GTK developers?
The tip, how to enable scrollbar’s arrow buttons disabled by default in GTK3 applications, is one of the hottest tips related to the Linux GUI. Obviously, there are users who need these buttons. How numerous they (we) are, I don’t know. And you? Do you have any statistics about user expectations concerning this question?
You need to remember what the psychological obsolescence is.
Replacing a typewriter without memory with a one with memory was an improvement.
Replacing a typewriter with memory with a text-processing software tool was an improvement.
Sometime later, another replacing, say the text-processing tool XYZ 6.0 with the next version 7.0, was not an improvement. At that moment, the industry in question becomes a “fashion industry”. Most parts of the IT industry occupied with development of standard desktop applications became a “fashion industry” somewhere in the 2000s.
Please consider reading the blog post(s), your first question is addressed there. The answer is touchpad and trackpoint users. But even for other pointing devices it is a poor interface. If a user needs buttons to scroll it is better to use the keyboard, or use an AT which can generate scroll events.
I have no personal statistics but there is plenty of literature on this, e.g. WCAG which advises click targets should be at least 44px by 44px, which the scroll buttons are much smaller than. That page also lists many other users who cannot use small click targets:
- Users who use a mobile device where touch screen is the primary mode of interaction;
- Users with mobility impairments such as hand tremors;
- Users who use a mobile device in environments where they are exposed to shaking such as public transportation;
- Users who have difficulty with fine motor movements;
- Users who access a device using one hand;
- Users with large fingers, or who are operating the device with only a part of their finger or knuckle;
- Users who have low vision may better see the target.
I disagree a typewriter with memory is an improvement. I am not a professional writer or typist so I only use a word processor to print small notes. A mechanical typewriter or even a pen or pencil would be just fine for me, the memory basically does nothing. So to me the “fashion” in this area goes back to at least the 1940s, or earlier.
Of course I think computers are useful in other areas so maybe you can see why it is not a good discussion for either of us to accuse various things of being a fashion industry.
It’s true, that the use-case I’d see in the steppers, would be for resistive-touch-only devices, without keyboards.
Therefore I would also make the steppers bigger. (For touch screens the scrollbar should be made much bigger anyway, it’s very hard to hit. It would need to be like 3 times the size it’s currently)
I am aware though, that this would be an incredibly niche setup for GTK.
Though I need to say, dealing with an issue about a feature by deleting the feature, instead of addressing the issue seems a bit dramatic.
If this is a mobile phone the answer is to have something similar to e.g. Apple AssistiveTouch, where you can configure it to have a large button that performs a scroll gesture. There is no need to make the scrollbar bigger as the entire area functions as drag-to-scroll.
The speed at which the scrolling happens through gestures, does not adjust with the amount of content within the area if I’m not mistaken.
Making scrolling very large areas painful, without the scrollbar. Inertia, iirc can only take you to a certain max speed which might be inappropriate for example for very very large text files.
In which case, you would use the scrollbar for fast navigation.
Either way, having a tiny scrollbar is also unbeneficial in my opinion for touch, as it might be accidentally tapped as well, offsetting the view unintentionally.
I think the idea of using buttons to do the scrolling isn’t bad.
But I would rather have a hybrid solution of both.
That should just be an accessibility setting to disable inertial scrolling. That is probably a good feature request to make if it has not been done already. (Edit: there is one: gtk#2263) For large areas I am not sure what you mean, app developers are supposed to configure the scroll areas to use roughly the same distances for scroll adjustments.
For very large text areas the GNOME Text Editor does already have that, i.e. the overview map is actually just a very large scroll bar.
Super! Then I definitely belong to the target group. For many years (or, even some decades), I have been working mostly with notebooks using them almost exclusively with built-in pointing devices (trackbols, Ergopoint, Trackpoint, touchpads, clickpads…). Just this experience is the reason why I would miss the arrow buttons by scrollbars.
Of course, I do not use them as the main input method for navigation within content. Arrow buttons are rather a subsidiary or fallback input method but an important one. I am regularly confronted with the situations where they are the best and sometimes even the only method to produce the needed effect. E.g., in a particular case, arrow buttons of a scrollbar can provide the finest granularity among all available input methods. Because the arrow buttons are subsidiary the small size is not an issue. But a full lack of them would be an issue.
These values are too large and they are not intended for Desktop and common situations (from the source: “Users lack the same level of fine control when using inputs such as a mouse or stylus”).
In general, we should be very careful by applying Web-standards to the Desktop. Web becomes mobile-only. There are websites where more than 90 per cent visitors use mobile devices. The button that occupies half of the screen of a smartphone can be considered user-friendly. The same by the screen of a notebook is a joke.
Web standards are intended for both desktop and mobile, just as GNOME is with libhandy/libadwaita. The page also lists other users besides touch screen users who will be impacted negatively by small click targets.
At least in GTK, any buttons will have to use the adjustment step size, and that is the same granularity as using the keyboard arrow keys.
My experience is different. E.g., in an instance of GtkTextView the Up/Down keys scroll the screen by one line while scrollbar arrow buttons scroll it by a smaller amount.
What is the purpose of only scrolling half a line? You will only see one half of the letters, it will be unreadable. AFAIK the step size is supposed to represent the minimum step for that reason.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.