Bug 396091 - Scrollbar appearance inconsistent in between Breeze themes
Summary: Scrollbar appearance inconsistent in between Breeze themes
Status: RESOLVED FIXED
Alias: None
Product: Breeze
Classification: Plasma
Component: gtk theme (other bugs)
Version First Reported In: 5.13.2
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: scionicspectre
URL:
Keywords:
: 390625 396284 (view as bug list)
Depends on:
Blocks:
 
Reported: 2018-07-02 12:51 UTC by grmat
Modified: 2018-11-28 15:00 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed/Implemented In: 5.15.0
Sentry Crash Report:


Attachments
screenshot of breeze scrollbars (1.07 KB, image/png)
2018-07-02 12:51 UTC, grmat
Details

Note You need to log in before you can comment on or make changes to this bug.
Description grmat 2018-07-02 12:51:45 UTC
Created attachment 113714 [details]
screenshot of breeze scrollbars

The Breeze scrollbar appearance has changed quite a lot, especially with commit d4b07d9e1daf0dd1185eda8c905c2f2c87541ccf[1] from January.

However, the change has only partially been adopted to breeze-gtk. Attached is an image that shows from left to right:
- breeze-gtk,
- breeze-gtk mouse hovering,
- breeze-gtk dark,
- breeze-gtk dark mouse hovering,
- breeze,
- breeze, mouse hovering

So especially the breeze-gtk dark theme has to catch up, it has an ugly fat scrollbar that doesn't suit the breeze design. Apart from size/shape, the scrollbar is not blue although the view has focus. Note that for the reference breeze/qt screenshot it's grey either, but that's because the view/window was not in focus.

Also, with breeze-gtk there is a fixed background color, while for Qt apps it looks like it's transparent. However, I'm not sure if that's a framework constraint.



Some additional thoughts: Sorry to say that, but breeze-gtk maintenance looks a bit sloppy. Some important changes like change of scrollbar appearance[2] or refactoring work [3] is only being done for the light theme. Is there a specific reason why both styles are being maintained separately instead of using common files, then colour files and @import?

Is anyone working on improving the situation? Because if not, let me know and I could have a look. The consistent look is important, I suspect not only for me, and there is need for some GTK+ apps that won't just go away by using Plasma.

[1]: https://cgit.kde.org/breeze.git/commit/?id=d4b07d9e1daf0dd1185eda8c905c2f2c87541ccf
[2]: https://cgit.kde.org/breeze-gtk.git/commit/Breeze-gtk/gtk-3.20/gtk.css?id=01a86601804222929441c0c1c8bb0db6d4ee2769
[3]: https://cgit.kde.org/breeze-gtk.git/commit/?id=1ea1e0f88d0812d0f7b8e542bd9eacee234a93ee
Comment 1 Nate Graham 2018-07-13 20:22:19 UTC
The differences between breeze-gtk and breeze-gtk-dark are likely a simple omission, the result of forgetting to update the dark variant. Oops.

Please feel free to get involved. We would be *thrilled* to have some help here! We use Phabricator to submit patches, and here's the documentation: https://community.kde.org/Infrastructure/Phabricator

Let me know what I can do to help you get started!
Comment 2 grmat 2018-07-14 11:19:06 UTC
> The differences between breeze-gtk and breeze-gtk-dark are likely a simple omission, the result of forgetting to update the dark variant. Oops.

That's what I thought. And that's why I also think that the code base should be reduced. There is no point in duplicating all the code for the dark theme if you could just share the basic stuff like layout, size, shape, ... and then only swap colours, is it?

> Let me know what I can do to help you get started!

Thanks, I've already done my first submission via Phabricator in the last days.

However, I have some additional suggestions. One is that many GTK+ themes are using Sass, which offers additional functionality over CSS like variables, some math and easier nesting/inheritage. Sass needs less code and can be compiled to CSS afterwards, so it's easier to maintain.
It would also be possible to replace GTK's own extensions, for example use variables which get replaced at CSS creation time rather than GTK's @define-color, which resides in the CSS. This would bring the opportunity to re-use the CSS on the web, if that's a use-case, I don't know. But to me it looks like some newer KDE web pages are using a Breeze-ish design.

But I'm not sure this is the right place to discuss any of this?
Comment 3 Nate Graham 2018-07-15 03:40:28 UTC
Not at all an inappropriate venue! ...Especially if you plan to submit patches. :)
Comment 4 grmat 2018-09-26 22:36:44 UTC
I've posted the related D15786 in phabricator.

If this change gets rejected, I can also offer an alternative manual patch, making the dark theme catching up with commit 01a86601804222929441c0c1c8bb0db6d4ee2769 and others. However, I'd prefer the first approach since it saves time now and in the future.
Comment 5 Nate Graham 2018-10-31 18:47:19 UTC
Git commit 6ec73bf0693821ffda1ea262e8b7c162242dc495 by Nate Graham, on behalf of Matthias Groß.
Committed on 31/10/2018 at 18:39.
Pushed by ngraham into branch 'master'.

share common values for both Breeze and Breeze-dark GTK themes

Summary:

As described in bug #396091, the Breeze-dark theme is often neglected in updates. This patch fixes #396091 and some additional, related inconsistencies, enables sharing the basic stuff like shape, size, style, etc. of components in a common single css file while keeping the colour definitions separated from that in different files for both the light and dark theme.
This allows easier changes, easier maintenance because of less LOC, less duplicate code as well as easier extensibility for potential additional colour schemes like [[ https://hig.kde.org/style/color/light.html | light ]] or [[ https://hig.kde.org/style/color/high.html | high-contrast ]].

I only did this for GTK 3.20 for now. If you like the effort, it could (and maybe should) get extended to other versions.

Further potential steps in the same direction of saving code would be going back to SASS, which is used by many other popular GTK themes and was used by Breeze-gtk as well in the past. The only downside of that is that the SASS source files would have to be "compiled" to CSS prior to packaging.

Test Plan: I don't know of any automated test suites comparing UI components. I have already posted screenshots in the original bug report and can post additional ones of the new state for comparison. Apart from that, my manual sparse testing makes me feel the dark GTK theme looks and feels much more consistent to Breeze now.

Reviewers: jackg, #breeze, #plasma, ngraham

Reviewed By: #breeze, ngraham

Subscribers: grmat, ngraham, plasma-devel

Tags: #plasma

Differential Revision: https://phabricator.kde.org/D16365

M  +60   -3707 Breeze-dark-gtk/gtk-3.20/gtk.css
C  +0    -122  Breeze-gtk/gtk-3.20/common.css [from: Breeze-gtk/gtk-3.20/gtk.css - 097% similarity]
M  +1    -3692 Breeze-gtk/gtk-3.20/gtk.css

https://commits.kde.org/breeze-gtk/6ec73bf0693821ffda1ea262e8b7c162242dc495
Comment 6 Nate Graham 2018-11-28 15:00:40 UTC
*** Bug 390625 has been marked as a duplicate of this bug. ***
Comment 7 Nate Graham 2018-11-28 15:00:47 UTC
*** Bug 396284 has been marked as a duplicate of this bug. ***