| Summary: | Option to disable window border introduced in 5.27 | ||
|---|---|---|---|
| Product: | [Plasma] Breeze | Reporter: | ricevacuum |
| Component: | window decoration | Assignee: | Plasma Bugs List <plasma-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | wishlist | CC: | 4wy78uwh, aoeui, breakingspell, bugs.kde.org.facelift226, dyle71, hotrongnghia310, hugorteg, kde, krystian.zajdel, kwin-bugs-null, linx.system.adm, me, nate, putr4.s, qydwhotmail, spam, subhuman2222, sydneysedai+kde, uhhadd, xanonix161 |
| Priority: | NOR | ||
| Version: | 5.27.0 | ||
| Target Milestone: | --- | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| Latest Commit: | https://invent.kde.org/plasma/breeze/commit/9b93fb968ed6a2817cee367aab5cfef7003b4073 | Version Fixed In: | 6.0 |
| Sentry Crash Report: | |||
| Bug Depends on: | 455248 | ||
| Bug Blocks: | |||
| Attachments: |
window borders 5.26.5 vs 5.27.0
Image of new border "eating" into dark window contents |
||
I 100% agree, im running OpenSUSE TW. I think that is because the (atrocious) breeze theme change. Probably the half-measure would be backporting the old breeze(?). I 100% agree, im running OpenSUSE TW. I think that is because the (atrocious) breeze theme change. Probably the half-measure would be backporting the old breeze(?). Created attachment 156385 [details] Image of new border "eating" into dark window contents Agreed. And it seems like a lot of other people are upset by this as well: https://www.reddit.com/r/kde/comments/113y9py/how_to_get_rid_of_the_white_border_around_window/ There's 3 problems with the new border: 1. It is really distracting with windows with dark contents or if dark theme is enabled. 2. People are confused about why it doesn't respect the "No borders" setting. 3. The border appears on the secondary monitor when maximizing a window on the primary. The most glaring issue for me personally is that the color choices make it seem like it "eats" into dark window contents even when it's not. I'm attaching a screenshot showing the behavior. Both the Mullvad and Konsole windows used to look flush with the window edge, and now the dark parts of the window contents look like they have an extra 1px padding. I know its part of the window frame, but the color choices make it so that it looks like it's actually chewing into the window contents. It's especially obvious at the meeting point between light and dark window contents (the corner area where the Konsole toolbars meet the terminal contents and the corner area where the green Mullvad toolbar meets the map). This is genuinely a very distracting change and I would very much like an option to disable this. Agreed on offering an option or a customizable colour (including "none"), since it unfortunately doesn't look that good on some colour combinations, including mine (dark blue) I would like to have an option as well. In my opinion Breeze already feels kind of busy with all the lines it has and now the decoration adds another one. Please allow us to disable it, its a constant distraction if you use a Dark theme *** Bug 466196 has been marked as a duplicate of this bug. *** Agreed, this looks terrible with dark breeze theme due to the colors of the border clashing with dark theme colors. We need a setting to disable this behavior ASAP. To me, the reason this border is so distracting is because it does not match the global/custom color schema. For instance, with an accent value of #007e7e, the border renders at #14a3a3. I'm guessing this was intentional due to this being intended as an accessibility feature. Absolutely should be an opt-in setting for those that desire a bright border, not the default. The "No Borders" window decoration setting is misleading in this state, I personally do not desire borders for any windows, period. The code has a routine to check for the No Borders and Sorry, hit enter by accident and submitted. The code checks for "no borders" and "no side-borders" to choose where to draw the outline, could that check be used to completely hide the border rather than adding "yet-another-checkbox"? (In reply to breakingspell from comment #11) > Sorry, hit enter by accident and submitted. > > The code checks for "no borders" and "no side-borders" to choose where to > draw the outline, could that check be used to completely hide the border > rather than adding "yet-another-checkbox"? Imho no, since there are people who want a border but no outline (e.g. me), and most certainly also people who want no borders but the outline, since apparently it was added for accessibility. (In reply to Christian (Fuchs) from comment #12) > (In reply to breakingspell from comment #11) > > Sorry, hit enter by accident and submitted. > > 9 > > The code checks for "no borders" and "no side-borders" to choose where to > > draw the outline, could that check be used to completely hide the border > > rather than adding "yet-another-checkbox"? > > Imho no, since there are people who want a border but no outline (e.g. me), > and most certainly also people who want no borders but the outline, since > apparently it was added for accessibility. I see what you mean after switching them off and on for myself. Would have thought the "No Borders" label would be definitive for any decorations though, new users would likely think the same. An intensity slider is in the works per the merge request, at least. (In reply to breakingspell from comment #13) > (In reply to Christian (Fuchs) from comment #12) > > (In reply to breakingspell from comment #11) > > > Sorry, hit enter by accident and submitted. > > > 9 > > > The code checks for "no borders" and "no side-borders" to choose where to > > > draw the outline, could that check be used to completely hide the border > > > rather than adding "yet-another-checkbox"? > > > > Imho no, since there are people who want a border but no outline (e.g. me), > > and most certainly also people who want no borders but the outline, since > > apparently it was added for accessibility. > > I see what you mean after switching them off and on for myself. Would have > thought the "No Borders" label would be definitive for any decorations > though, new users would likely think the same. > > An intensity slider is in the works per the merge request, at least. Good. I don't know what the hell they were thinking, just adding outlines to all windows without any configuration available of any sort. Could we please try to stay friendly and within the KDE CoC? I would have preferred an option, but it's easy enough to revert for now without breakage (just downgrade one single .so file), and attacking designers, devs or anyone really doesn't help matters at all. Git commit 9b93fb968ed6a2817cee367aab5cfef7003b4073 by Akseli Lahtinen. Committed on 03/03/2023 at 20:51. Pushed by akselmo into branch 'master'. Outline intensity setting This MR adds a tiny outline intensity combobox to Breeze settings in the Shadow tab. I chose shadow tab since the outline is drawn in the shadow drawcall, so maybe this will help people realise it's not part of the borders. FIXED-IN: 6.0 --- Here's examples with default breeze dark theme Off  Low  Medium  High  Maximum  Currently the effect only appears after pressing OK. This is same with all the Breeze window decoration settings afaik. _Also, dont mind the settings window having same outline at the same time in the images: I'm not using the dev environment so it doesnt affect anything outside of the preview image. In dev env it changes everywhere._ M +52 -30 kdecoration/breezedecoration.cpp M +10 -0 kdecoration/breezesettingsdata.kcfg M +12 -0 kdecoration/config/breezeconfigwidget.cpp M +47 -5 kdecoration/config/ui/breezeconfigurationui.ui https://invent.kde.org/plasma/breeze/commit/9b93fb968ed6a2817cee367aab5cfef7003b4073 *** Bug 467500 has been marked as a duplicate of this bug. *** |
Created attachment 156382 [details] window borders 5.26.5 vs 5.27.0 Borders look ugly on my colorscheme now, see attached picture. I propose a toggle setting to bring back old (5.26.5) behaviour. I just don't get it why we need visible borders on "no borders" setting.