Breeze scrollbar look-and-feel unification
Open, Needs TriagePublic

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.Wed, Jul 4, 12:17 PM
abetts added a project: VDG.Wed, Jul 4, 5:31 PM
abetts added a comment.Wed, Jul 4, 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...