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:
|App||Track background color||Track and bar visibility when content isn't scrollable||Bar overlaps content?|
|Dolphin||Matches parent view's background color||Disappears||No|
|Konsole||Matches parent view's background color||Remains visible||No|
|Gwenview||Matches parent view's background color||Disappears||No|
|Okular||Matches parent view's background color, except for main view which is always the default color||Disappears||No|
|Kirigami apps/views||No track||Disappears||Yes|
|GTK apps using Breeze theme||Light gray||Disappears||No|
This inconsistency is not ideal. I see two options to move forward:
- 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.
- 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:
- 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.
- 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.