ScrollView: Do not overlay scrollbars over contents
ClosedPublic

Authored by ahiemstra on Jan 8 2020, 8:08 PM.

Details

Summary

This ensures the scrollbar of a ScrollView do not overlap the ScrollView's
contents. It effectively makes ScrollView's behaviour the same as all
widget views, which also do not overlap the contents.

It also removes the need for a lot of workarounds in applications and other
places to fix the overlapping problem.

Test Plan

Tested with this QML:

import QtQuick 2.12
import QtQuick.Controls 2.12

import org.kde.kirigami 2.11 as Kirigami

Kirigami.ApplicationWindow {
    pageStack.initialPage: Kirigami.Page {
        leftPadding: 0
        rightPadding: 0
        topPadding: 0
        bottomPadding: 0
        ScrollView {
            anchors.fill: parent

            ListView {
                model: 100

                delegate: ItemDelegate {
                    width: ListView.view.width
                    text: modelData
                }
            }
        }
    }
}

Before:

After:

Diff Detail

Repository
R858 Qt Quick Controls 2: Desktop Style
Branch
scrollview_scrollbar_spacing
Lint
No Linters Available
Unit
No Unit Test Coverage
Build Status
Buildable 21098
Build 21116: arc lint + arc unit
ahiemstra created this revision.Jan 8 2020, 8:08 PM
Restricted Application added a project: Plasma. · View Herald TranscriptJan 8 2020, 8:08 PM
Restricted Application added a subscriber: plasma-devel. · View Herald Transcript
ahiemstra requested review of this revision.Jan 8 2020, 8:08 PM
cfeck awarded a token.Jan 8 2020, 8:11 PM
broulik added a subscriber: broulik.Jan 8 2020, 8:31 PM

I thought back then we explicitly did not want that?
Also, how does this behave on mobile, ie. "transient scrollbars"?

I think overlay scrollbars just cause more problems than they solve. Basically every application developer needs to account for the scrollbars, rather than just using ScrollView without bothering about it. Additionally, as mentioned, it is inconsistent with all the other views we use.

As for mobile, since it is called the "QtQuick Controls 2 Desktop Style" I was assuming mobile was out of scope.

every application developer needs to account for the scrollbars

Says who? If the standard qqc2 desktop style item delegate and kirigami list delegate take it into account for their padding reliably you get 99% covered.

I was assuming mobile was out of scope.

Well, there's also touch and convertibles, and I thought we wanted to be "responsive" in that sense. Might be for Kirigami, though, but I do think we use it on PlaMo as well.

ngraham added a subscriber: ngraham.

From T9126, the proposal is to use disappearing overlay scrollbars on mobile, and regular/old fashioned separated non-disappearing scrollbars on the desktop. This is what QWidgets apps already do, but QML apps on the desktop use an odd hybrid where the scrollbar is overlay-style and neither disappears nor overlaps the content because the content is re-shuffled to accommodate it. I don't really think it works IMO, and I agree with @ahiemstra they it just causes more problems than it solves. Also it's inconsistent with the conventional style on both desktop and mobile, while we're supposed to be focusing on Goal: Consistency. So +1 overall.

Would this require changes in all apps to undo their special support for the current style though? I still see overlaps in the Audio KCM for example, which uses the QQC2 desktop style:

Visually, this looks like a step back to me... Do you also envision Konsole using opaque overlay scrollbars again?
The current scrollbar appearance is quite common on desktop (Telegram and GNOME apps come to mind), so it's not odd/out-of-place by any means.

it is inconsistent with all the other views we use

Doesn't mean by default that the most common pattern is better... especially if it comes across as "old fashioned"

it just causes more problems than it solves

Haven't heard of related issues before, could you give an example?

Visually, this looks like a step back to me... Do you also envision Konsole using opaque overlay scrollbars again?

Konsole doesn't use overlay style scrollbars; it simply colors its scroll track to blend in with the view. Dolphin does the same thing. So nothing would change with those kinds of apps.

The current scrollbar appearance is quite common on desktop (Telegram and GNOME apps come to mind), so it's not odd/out-of-place by any means.

Actually not. Telegram uses Mobile-style disappearing overlay scrollbars. Overlay scrollbars are fine if they disappear, because then problems of overlapped content disappear along with the scrollbar.

it just causes more problems than it solves

Haven't heard of related issues before, could you give an example?

  1. Inconsistent with Scrollbars in QWidgets apps
  2. Scrollviews with custom content (e.g. not any of the basic list/grid delegates) need to manually account for the scrollbar positioning
  3. This behavior is seen in the KDE QQC2 Desktop Style, but other QQC2 themes might not implement this behavior, causing apps' custom positioning logic to break
  4. The "dodge scrollbars" behavior of list/grid items that have this behavior built in has broken multiple times in memory (an example can be seen in D26506)

In a nutshell:
Overlay scroll bars disappear. Separated scrollbars stay visible. The QQC2 style scrollbars in question stay visible but try to use an overlay style anyway, and to make this work they overlap the scrollview's background but try to avoid overlapping the content on top of the background by requiring that items in scrollviews implement layout hacks to move out of the way of the scrollbar when it's visible. This is messy, breakable, and consistent with neither mobile nor desktop style scrollbars.

Inconsistency is fine if it's an innovation that offers tremendous advantages over the things it's inconsistent with, but I don't really see evidence of that here.

ngraham added a comment.EditedJan 8 2020, 11:44 PM

It might be worth comparing with what other platforms do:

  • Windows: old apps use real separated always-visible scrollbars; new apps use real overlay scrollbars that overlap content but disappear when not in use
  • macOS: all apps use real overlay scrollbars that overlap content but disappear when not in use, but if you hate them you can replace them all with real separated always-visible scrollbars
  • GNOME: real overlay scrollbars, but instead of disappearing entirely, they become so thin and tiny that they're almost invisible (though they are actually still slightly visible) and don't overlap any interactive UI elements

I would really like to do what macOS does, and allow you to choose between whether to use real overlay scrollbars or real always-visible scrollbars.

ndavis added a subscriber: ndavis.EditedJan 9 2020, 4:49 AM

+1 to not using overlay scrollbars on desktop

mart added a subscriber: mart.Jan 10 2020, 11:54 AM

It might be worth comparing with what other platforms do:

  • Windows: old apps use real separated always-visible scrollbars; new apps use real overlay scrollbars that overlap content but disappear when not in use
  • macOS: all apps use real overlay scrollbars that overlap content but disappear when not in use, but if you hate them you can replace them all with real separated always-visible scrollbars
  • GNOME: real overlay scrollbars, but instead of disappearing entirely, they become so thin and tiny that they're almost invisible (though they are actually still slightly visible) and don't overlap any interactive UI elements

    I would really like to do what macOS does, and allow you to choose between whether to use real overlay scrollbars or real always-visible scrollbars.

I find the proposed patch a clear step back visually.
of the alternatives there, the one i would prefer, is actually the Gnome way (perhaps with the line slightly more visible, the super thin thing has quite a value of saying where is in the scrolling, i would like that *even* on mobile)

Yeah, I really dislike the fully-disappearing scrollbars too, for the same reason. I also like the GNOME approach when overlay-style scrollbars absolutely have to be used. That seems like a genuine innovation.

However I've found myself surprised by the volume of comments I've received over the past year or two from users across all platforms (emails, blog comments, social media, bug reports) complaining about the thin scrollbars. There seems to be a lot of user irritation by our changes here.

Personally I have to agree. I just don't see the problem with old-fashioned scrollbars with a visually separated track on the desktop. They clearly communicate your position in the scrollable view, their large click area makes them easy to grab, and they're not ugly if you render the track nicely.

There's a Goal: Consistency angle too. We don't want scrollbars in Kirigami and other QML apps on the desktop to look different from the scrollbars in QWidgets-based apps.

Also note that the intention is to have the scrollbar background match the view background. In the example case I didn't bother with any view specific styling, so it looks a little more ugly than necessary. This is what it would look like with fixed background styling:

I wouldn't be opposed to having a toggle somewhere, but someone will need to implement the QStyle side, and I don't know how feasible it is to implement for widgets.

Interestingly enough, I noticed that the Plasma style actually uses fixed scrollbars as well, so there even seems to be an inconsistency in QtQuick related controls.

All the various pieces of software that use fake overlay-style scrollbars by simply making the track disappear and blend in with the background (e.g. Konsole, Dolphin, Plasma) appear to have successfully fooled everyone into believing that they're real overlay-style scrollbars. :) Since nobody seems to object to that look, maybe that's what we should go for universally on the desktop.

Example when current way looks bad: D22176. We can live with that and add margins/padding when needed. Or not :)

  • Old-fashioned scrollbars are also bad, they look old and sometimes ugly (especially when list has different styles for odd and even rows). All other systems are moving (or moved) away from this.
  • Gnome way is not good either, at least from my experience. It is not intuitive, I'm always trying to scroll using this tiny bar, then realize that it shows bigger version on hover.
  • Disappearing is also not good, because it confuses user - sometimes they don't know that list has more elements, you need to hover a mouse over each widget to know the status. From the other side it is consistent with mobile, which is now a reference and most user are more accustomed. Maybe lists that have scrollbars (hidden) should have subtle fade-away effect on edges?

Nothing is perfect. That's why I hate creating UIs :)

Example when current way looks bad: D22176. We can live with that and add margins/padding when needed. Or not :)

  • Old-fashioned scrollbars are also bad, they look old and sometimes ugly (especially when list has different styles for odd and even rows). All other systems are moving (or moved) away from this.
  • Gnome way is not good either, at least from my experience. It is not intuitive, I'm always trying to scroll using this tiny bar, then realize that it shows bigger version on hover.
  • Disappearing is also not good, because it confuses user - sometimes they don't know that list has more elements, you need to hover a mouse over each widget to know the status. From the other side it is consistent with mobile, which is now a reference and most user are more accustomed. Maybe lists that have scrollbars (hidden) should have subtle fade-away effect on edges? Nothing is perfect. That's why I hate creating UIs :)

Yeah.

So in a nutshell:

  • The new thin/disappearing styles have worse usability but may look better
  • The old fashioned thick always-visible style has better usability but may look ugly

I think this is why the best compromise for desktop usage is to use thick always-visible scrollbars but improve aesthetics by making the track blend in with the view. Then it //looks like an overlay-style scrollbar but it has all the usability benefits of the old-fashioned always-visible style.

ahiemstra edited the test plan for this revision. (Show Details)Jan 13 2020, 11:31 AM
mart requested changes to this revision.Jan 13 2020, 11:41 AM

I think this is why the best compromise for desktop usage is to use thick always-visible scrollbars but improve aesthetics by making the track blend in with the view. Then it //looks like an overlay-style scrollbar but it has all the usability benefits of the old-fashioned always-visible style.

:((((
i really don't like this direction :(

the konsole approach can look broken pretty easily, and is shown by the screenshot directly.
the higlight reactangle being truncated like that into nothingness really looks pretty bad.

It would already be much better if the track was actually very visible, visually delimiting the space

Tough i remain on my opinion that it should be changed everywhere to go fully on Gnome way (but keeping the same current hit area)

Also, on the after screenshot the thing i really don't like is the appearance of the frame, which makes things look super ugly, especially when that scrollview is used as a sidebar, a very unpolished and unprofessional look.

I tought that our goal was instead to get rid of as many frames as possible on the qwidget apps instead :(

This revision now requires changes to proceed.Jan 13 2020, 11:41 AM
mart added a comment.Jan 13 2020, 11:43 AM

Also note that the intention is to have the scrollbar background match the view background. In the example case I didn't bother with any view specific styling, so it looks a little more ugly than necessary. This is what it would look like with fixed background styling:

I wouldn't be opposed to having a toggle somewhere, but someone will need to implement the QStyle side, and I don't know how feasible it is to implement for widgets.

Interestingly enough, I noticed that the Plasma style actually uses fixed scrollbars as well, so there even seems to be an inconsistency in QtQuick related controls.

I would really not want new useless borders added when we want actually kill as many of them as possible even in qwidgets :/

mart added a comment.Jan 13 2020, 11:55 AM

Yeah, I really dislike the fully-disappearing scrollbars too, for the same reason. I also like the GNOME approach when overlay-style scrollbars absolutely have to be used. That seems like a genuine innovation.

However I've found myself surprised by the volume of comments I've received over the past year or two from users across all platforms (emails, blog comments, social media, bug reports) complaining about the thin scrollbars. There seems to be a lot of user irritation by our changes here.

the hit target didn't decrease, and they are still very visible. The only thing behind this widespread complaint is really a perception of "is a new trend, therefore it must be bad" no matter if it's well balanced and the good things of such trend have been taken, fixing the problems

Personally I have to agree. I just don't see the problem with old-fashioned scrollbars with a visually separated track on the desktop. They clearly communicate your position in the scrollable view, their large click area makes them easy to grab, and they're not ugly if you render the track nicely.

I do see a problem with it. Qt apps (in general, also beyond the KDE bubble) *do* have a reputation for looking clunky, outdated, and windows95 like, perception i would like to fight, not encourage.

There's a Goal: Consistency angle too. We don't want scrollbars in Kirigami and other QML apps on the desktop to look different from the scrollbars in QWidgets-based apps.

yes, i would like the qwidget ones to look better instead :/

In D26530#592999, @mart wrote:

It would already be much better if the track was actually very visible, visually delimiting the space

I think it looks fantastic, or at least it would if that vertical line touched the top and bottom of the view, and the bar were wider so it did a better job of taking up the space in the track. This is in fact how macOS looks when you disable overlay-style scrolling globally, and personally I would like this everywhere -- at least on the desktop. On mobile, then sure, the scrollbars cam be tiny and almost/entirely disappearing. But I just don't like this style on the desktop. I don't think it's a case of, "it's new, I hate it." I'm pertty open to change, and I lived with it on and off on macOS since 2011 (see http://osxdaily.com/2011/08/03/show-scroll-bars-mac-os-x-lion) but never got used to it.

In D26530#592999, @mart wrote:

I do see a problem with it. Qt apps (in general, also beyond the KDE bubble) *do* have a reputation for looking clunky, outdated, and windows95 like, perception i would like to fight, not encourage.

I agree. However personally I think this impression comes from how typically each view is put within its own frame, rather than separating adjacent views with single-pixel lines like how Kirigami does it (which solves the problem). This leads to horrible frame overload like so:

I don't think the size of the scrollbars has much to do with it.

mart added a comment.Jan 13 2020, 2:28 PM
In D26530#592999, @mart wrote:

It would already be much better if the track was actually very visible, visually delimiting the space

I think it looks fantastic, or at least it would if that vertical line touched the top and bottom of the view, and the bar were wider so it did a better job of taking up the space in the track. This is in fact how macOS looks when you disable overlay-style scrolling globally, and personally I would like this everywhere -- at least on the desktop. On mobile, then sure, the scrollbars cam be tiny and almost/entirely disappearing. But I just don't like this style on the desktop. I don't think it's a case of, "it's new, I hate it." I'm pertty open to change, and I lived with it on and off on macOS since 2011 (see http://osxdaily.com/2011/08/03/show-scroll-bars-mac-os-x-lion) but never got used to it.

I may take a look into changing the breeze style do do such line, tough i would like that:

  • breeze qwidget also supports disappearing scrollbar on touch (and hmm, configurable :p)
  • on mobile scrollbar behavior is always hiding, and overlay
  • even change on the fly when flicking a view with touch (and change back when the mouse is used): this is fine to be qml only as flicking is not really going to work correctly with qwidgets.

I agree. However personally I think this impression comes from how typically each view is put within its own frame, rather than separating adjacent views with single-pixel lines like how Kirigami does it (which solves the problem). This leads to horrible frame overload like so:

I don't think the size of the scrollbars has much to do with it.

yes, i'm saying that the patch besides putting the separation in the frame, it also reintroduces the frame by default, which is unrelated (and i think it should be avoided)

mart added a comment.Jan 13 2020, 2:29 PM

i'm giving a try to give breeze qstyle that look, then we can revisit this

In D26530#593152, @mart wrote:

yes, i'm saying that the patch besides putting the separation in the frame, it also reintroduces the frame by default, which is unrelated (and i think it should be avoided)

Let's distinguish and lines. A frame is a four-cornered outline. What we see in the following image has no frames:

IMO using lines to separate distinct elements that touch the bounds of the window is 1000% better than putting everything in a frame floating on the view, separated by a few pixels of padding. You can add more lines (within reason) without the view becoming overwhelming and heavy and old-fashioned looking I love love love the Kirigami style that does this, and in fact our T10891: Breeze theme evolution task proposes moving to this style for QWidgets apps too.

yes, i'm saying that the patch besides putting the separation in the frame, it also reintroduces the frame by default, which is unrelated (and i think it should be avoided)

The patch as-is does not, what you see is the default scrollview background that I enabled in my tiny test. This patch actually just makes the space for the scrollbar, since the scrollbar itself was not changed whatever is underneath becomes visible. With the default scroll view background enabled that becomes the frame, but it can easily just be a view-colored rect.

ahiemstra added a comment.EditedJan 13 2020, 3:36 PM

Also, just want to reiterate that I actually don't really care about how things look, what I care about is the amount of workarounds that are introduced by the scrollbar behaviour as it is. One current example is D26586 but I have ran into this myself when doing application development, as well as seen other people run into it. The workarounds introduced easily break, either with a different QtQuick Controls style or even with just a different widget style. Take a look at the System Settings sidebar with Oxygen for example. They also repeat code and lead to bugs due to that, like missing handling of LayoutMirroring.

mart added a comment.Jan 13 2020, 4:47 PM

ok for it, provided it still has overlay scrollbars on tablet mode

org.kde.desktop/ScrollView.qml
47

those properties should be top level, (even starting with _ )
there is stuff inside data: already, it can be put inside there

48

it should also have the condition: !Kirigami.Settings.tabletMode

ahiemstra updated this revision to Diff 73495.Jan 14 2020, 9:56 AM
  • Review comments
ahiemstra marked 2 inline comments as done.Jan 14 2020, 9:56 AM
mart accepted this revision.Jan 14 2020, 9:58 AM
This revision is now accepted and ready to land.Jan 14 2020, 9:58 AM
This revision was automatically updated to reflect the committed changes.

This has caused a regression in the plasma-pa KCM. The scrollview content is now a bit larger than the scrollview itself which results in a horizontal scrollbar appearing