ngraham added a comment.
In D26530#590649 <https://phabricator.kde.org/D26530#590649>, @IlyaBizyaev wrote: > 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 <https://phabricator.kde.org/D26506>) REPOSITORY R858 Qt Quick Controls 2: Desktop Style REVISION DETAIL https://phabricator.kde.org/D26530 To: ahiemstra, #plasma, #goal_consistency Cc: IlyaBizyaev, ngraham, broulik, plasma-devel, LeGast00n, The-Feren-OS-Dev, jraleigh, zachus, fbampaloukas, GB_2, ragreen, ZrenBot, alexeymin, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart
