The new base colour for Breeze Dark is #141618
, the colour in your screenshot is #111111
which I agree is too dark
I just tried #141618
, it is still too dark, the higher contrast strains my eyes more than the previous more calm one. With dolphin it looked a bit harsh with many âtextâ icons (i.e black and white). I donât think it will be that comfortable working with it in the long run, from all those Iâd prefer most probably your first iteration, #16181b
, removing basically the âdazzleâ was all it was needed imo. Steam Deckâs âVaporâ #151c23
feels way more comfortable too (and more elegant than the âsterilâ black-grey-brown) in comparison.
I think in your screenshot I canât recognize KDE anymore, itâs more like Solus Budgie, slightly âlighterâ.
so itâs good that I follow the blog, I will save the current Breeze Dark as Breeze Dark Classic .
@rockandstone, you can always get the old colours from invent.kde.org/plasma/breeze/-/commit/9c13ba31ea59225ba71922f7066b2ec41a6a0206#e94d132ec30abc41091d3f30decb471a9d0e8d51
if you lose your .colors
file.
I also do have concerns regarding theme getting more contrast-y. So as others mentioned being easy on the eyes is a great feature, and one could say the primary goal.
For me the old theme is in best way boring: it does not steal attention, gets out of the way and, again, is easy on the eyes.
My only question would be is this final? What do we do with community concerns? I guess backing up old theme is not really an option, since it wont get updates and bugfixes and in a way would be just another custom theme without official support
An idea just hit me, a community effort to maintain the old code, like that open source / free software stuff I hear about does. If enough people care about it it will be done if not it gets to die off from the eventual bit rot that will happen to the saved themes.
@JohnBrown, itâs markup. The distinction between that and programmatic code matters (in this context, at least):
@UncleInf, the API surface, so-to-speak, for .colors
files has been fairly stable for some years (itâs a .desktop
file, which adheres to .ini
syntax). However, your concerns are founded. Luckily, the solution is fairly simple:
As long as one person duplicates the content of the file in commit previous to that which Iâve referenced to a git
repository, you can clone the repository into your $HOME/.local/share/color-schemes/
. Then, when the very occasional change happens, someone takes 5 mins to update the theme, and you all get it.
I have no clue on it really about what it uses. The defaults the people at KDE come up with have always been fine for me. I have never once even tried to use a different one. Even when the come up with the butt ugly login screens they do from time to time. I leave them in place as I do not see it often enough to care about them.
@JohnBrown, how does what youâve quoted and what youâve described relate?