Breeze scrollbar look-and-feel unification
Closed, ResolvedPublic

Description

KDE apps and GTK apps run within a KDE Plasma environment are currently inconsistent regarding their scrollbar behavior. With the default settings (Breeze theme and Breeze light color scheme), here's the situation:

AppTrack background colorTrack and bar visibility when content isn't scrollableBar overlaps content?
DolphinMatches parent view's background colorDisappearsNo
KonsoleMatches parent view's background colorRemains visibleNo
GwenviewMatches parent view's background colorDisappearsNo
OkularMatches parent view's background color, except for main view which is always the default colorDisappearsNo
Kirigami apps/viewsNo trackDisappearsYes
GTK apps using Breeze themeLight grayDisappearsNo

This inconsistency is not ideal. I see two options to move forward:

  1. Declare that Breeze's minimalistic style is best suited for overlap-style scrollbars and use them everywhere; decide that people who don't like overlay-style scrollbars should to use a different theme.
  2. Make the scrollbar style configurable within Breeze, and have apps adjust themselves to support both options.

My personal preference is for option #2; I think it would be a shame to tell people who don't like overlay-style scrollbars (I admit to being such a person) that they need to abandon Breeze entirely.

If we make it configurable within Breeze, here are the two options that should be available:

  1. Traditional scroller-within-a-track. Appears when the content is scrollable, and disappears when content is not scrollable. When the view becomes scrollable, to avoid overlapping any of the content with the scrollbar, the content does a re-layout, resizes itself, or gains a horizontal scrollbar (depending on the app and context). The track makes no special attempt to blend into the view background and is visually separated with a single-pixel line.
  1. Overlay-style scroller. There is no separate track; the bar disappears when content is not scrollable, and overlaps the content when the view is scrollable.

The thinking here is that Option 1 will appeal to "form follows function" people who like traditional scrollbars and don't want them monkeyed with. Option 2 will appeal to the "I really like smartphones" crowd and brings overlay-style mobile scrollbars to the desktop--while keeping them constantly visible to preserve some of the functionality of traditional scrollbars.

For apps that cannot implement all of the above options (maybe GTK apps?) they should come as close as possible.

Thoughts?

ngraham created this task.Jul 4 2018, 12:17 PM
abetts added a project: VDG.Jul 4 2018, 5:31 PM
abetts added a comment.Jul 4 2018, 5:33 PM

I am interested in keeping the visual consistency across all applications. I think it is a good thing to provide a setting that allows users to tweak this. Once we have a configurator, would settings in it apply to all applications or would these settings apply per application?

Good analysis, that's what I like to see at the start of any changes!

Only one comment is the "Remains visible when not scrollable" column. From a code POV it's up to the app developer both in widgets and QtQuick not something you can control in the style.

In something like konsole you definitely don't want to resize contents when you reach a certain length and you need some hint between a new tab and a user just typing "reset".
You'll see it in kate and many other places too (see https://lxr.kde.org/ident?_i=setVerticalScrollBarPolicy&_remember=1 )

It might need a rule, and maybe some cases are wrong but it's not something that should be arbitrarily unified.

Ok, that's fine. So our two scrollbar style options are basically:

  • Track and bar are separated from content
  • No track, bar overlaps content

And in both cases, the bar (and track, if applicable) may or may not disappear when view is not scrollable; this is up to app developer. Though for overlay style scrollbars, since there is no separate track, I'm not sure how this would work exactly...

elcste added a subscriber: elcste.Feb 18 2019, 11:37 PM
filipf added a subscriber: filipf.Jun 28 2019, 8:46 PM

+100 for this goal. One thing we should definitely fix is scrollbars overlapping content. The rest I don't care too much tbh, but it would probably look better if we didn't separate the track and the bar from the content (as the default).

elcste removed a subscriber: elcste.Jun 28 2019, 10:15 PM
ndavis added a subscriber: ndavis.Jun 28 2019, 10:45 PM
mglb added a subscriber: mglb.Jun 28 2019, 11:36 PM

Why not both? Every desktop goes forward with UI design and provides limited UI versions for legacy code. By default overlay scrollbars can't be used, as Qt apps assume that nothing blocks visible content in scroll areas. Regular scrollbars have to be supported also for standalone scrollbar widgets. But when app is made to work well with overlay scrollbars and it is not disabled in breeze settings, why not turn them on on app request?

This is happening; see the linked patches. Here's what's happening:

  • On the desktop, scrollbars return to their prior thickness and are always visible in a separated track regardless of the toolkit (QTWidgets, bare QQC2 on desktop, Kirigami on desktop
  • On mobile with Kirigami or bare QQC2, scrollbars are always overlay style with no layout hacks, which means they can cover the content while in use. When not in use, they flatten out and hug the edge, remaining (barely) visible to serve as an indication of scroll position without getting in anyone's way

This seems like a great resolution to me.

ngraham closed this task as Resolved.Jan 19 2020, 3:11 AM
ngraham moved this task from Backlog/Planned to Done on the Breeze board.
ngraham claimed this task.

Welp, this is done now!