The 32px icons need to be 32x32, not 54x54.

In D22884#505718, @aspotashev wrote:

In D22884#505656, @ndavis wrote:

Perhaps it is technically a bug, but it seems to me that most of the time (at least in all of the KDE programs I have installed), the title is just the section name, "Configure (the) [section name]" or "[secion name] Options". In Krita, the page titles are sometimes even shorter than the section names. However, if the bug is so widespread and the intended way of using a page title is so rare, perhaps we should disable page titles by default? It also seems to me that if a page needs an additional description that the user can't see until they get to the page, perhaps the section name isn't accurate or descriptive enough?

It's not always "Configure [section name]". You can't have a long section name or it would be truncated. When the section name can't describe all the aspects of a KCM, its title can be used to elaborate.

Examples:

• section name "KDE Connect", title "Connect and sync your devices"
• section name "Screen Edges", title "Active Screen Corners and Edges"

actually, you can disregard my inline comments on the 32px icons, I didn't realize you had already removed the duplicate fill currentColor bits. BTW, none of the code for style= matters as long as you have fill="currentColor" and the color class since we're not using strokes or opacity.

In D22653#505439, @lavender wrote:

[snip]
And the 32 one has a transform that can be applied:

<svg xmlns="http://www.w3.org/2000/svg" id="svg938" width="54" height="54"><style id="current-color-scheme">.ColorScheme-Text{color:#232629}</style><path fill="currentColor" stroke-width="2" d="M27 9V7h2v2zm0 6v-2h2v2zm-4 2v-4h2v4zm24 24v2h-2v-2zm2-2v2h-2v-2zm-8 6v2h-4v-2zm-2 0v2h-2v-2zm0 4v2h-2v-2zm4-2v4h-2v-4zm8 4h-4v-2h4zm-4-4v4h-2v-4zm2-2v2h-6v-2zm2-4v4h-2v-4zm-18 2h2v2h-2zm2 2h2v2h-2zm-4 4v-2h6v2zm12-14h-2v-2h2zm0-2h-4v-2h4zm-6 0h-2v-2h2zm-6 2h2v4h-2zm0 4h2v2h-2zm20-12h-2v-4h2zm0-2h-2v-2h2zm-2-2h-6v-2h6zm-2 2h-2v-2h2zm2 4h-4v-2h4zm-4 8v-4h2v4zm4-4h-4v-2h4zm2 2h-2v-6h2zm0 4h-4v-2h4zm-16-8h-2v-4h2zm4-8h-2v-2h2zm-2 4h-4v-4h4zm2 4h-2v-2h2zm0-2v-4h2v4zm4-4h-4v-2h4zm2 2h-2v-2h2zm0 4h-4v-2h4zM13 21h2v4h-2zm10 8h2v2h-2zm-2-2h2v2h-2zm0 22h6v2h-6zm10 0h2v2h-2zm-10-4h2v2h-2zm2 2h2v2h-2zm4-4v4h-2v-4zm0 4h2v2h-2zm2 0v-8h2v8zm-8-8h8v2h-8zm14 2h6v2h-6zm6 2v-8h2v8zm0-6h-6v-2h6zm-4-2v6h-2v-6zm-10-2v4h-2v-4zm-4 4h4v2h-4zm-8-8h4v2h-4zm6 2h4v2h-4zm10-2v-2h2v2zm-4 4v-4h2v4zm2 2v-8h2v8zM25 5V3h2v2zm0 8v-2h2v2zM9 29h2v2H9zm14-8h4v2h-4zm-6 0h4v2h-4zm2 2h4v2h-4zm-4 2h14v2H15zm-4 0h4v4h-4zm-2-4h2v2H9zm0 2v4H7v-4zm-4 4h4v2H5zm-2-2h2v2H3zm0 6h8v2H3zm0-10h4v2H3zm24-2v-2h2v2zm6 0H21v2h12zm-12 0v-8h2v8zm8-2v-2h2v2zm2 4V11h2v10zm-2-10V9h2v2zm2-2V7h2v2zm-2-2V5h2v2zm0-2V3h4v2zm-8 4V5h2v4zm2 2V3h2v8zM7 47v-8h8v8zm-4 4v-2h16v2zm16 0h-2V35h2zm0-16v2H3v-2zM3 35h2v16H3zm36-20V7h8v8zm-4 4v-2h16v2zm16 0h-2V3h2zm0-16v2H35V3zM35 3h2v16h-2zM7 15V7h8v8zm-4 4v-2h16v2zm16 0h-2V3h2zm0-16v2H3V3zM3 3h2v16H3z" class="ColorScheme-Text"/></svg>

I used svgo to make these optimizations.

In D22884#505651, @cfeck wrote:

The header title is usually more descriptive (longer) than the icon name, so no.

I was hesitant about making this change before I committed it, so it's not a knee jerk reaction, but I also don't think it's important for me to land this quickly. I might want to see if I can come up with the real solution.

I'll review this when I'm back from my vacation. I don't have my laptop with me.

In D22359#504108, @davidedmundson wrote:

Can you give a bit more rationale?

In D22653#504138, @lavender wrote:

I noticed that only the 22px icons use the viewbox, is this intentional?

As for the 32px one the validator I used complains that:

Error: Attribute paint-order not allowed on SVG element path at this point.

    From line 7, column 5; to line 7, column 1521

    tyle>↩    <path class="ColorScheme-Text" fill="currentColor" style="fill:currentColor;fill-opacity:1;stroke:no… 16v-2h16v2zm16 0h-2V3h2zm0-16v2h-16V3z" paint-order="markers fill stroke" transform="rotate(-90)"/>↩</s

I'm currently on vacation and can't access my laptop. Could you show me a screenshot of the 32px icon at 1x size?

In T10201#193268, @johan.boule wrote:

In T10201#189792, @ngraham wrote:

In T10201#189791, @alex-l wrote:

The important thing is preserving the current ease in distinguishing active window from inactives (for all windows, not only Qt/KDE ones)

Absolutely. It's a top priority. In addition, I think this will be improved for Breeze Light and Breeze dark, which currently have virtually no visual difference for active vs inactive windows.

I don't understand. At the top of this page, it started by showing screenshots of Breeze Light where the active window titlebar is very clear.
This is a good thing, right?
So in the end, when the OP said "Breeze: Having the titlebar color differ from the window color kind of looks unattractive", aren't you all saying, no, this is a good thing?
(side note: "attractiveness" shouldn't be considered alone, as there are more long-term aspects to love or dislike, like usability)

Seems to me the consensus after all these comments are:
Light Breeze active window: good
Light Breeze inactive window: bad
Dark Breeze active window: bad
Dark Breeze inactive window: bad

Shouldn't there just be *distinguishable* colors for the active tiltebar, active border, inactive titlebar, inactive border, and content of window? The menus and toolbars should have their own distinct color(s) or it's gonna look super confusing. I know for a fact that it's not of any use to have the content of a window change when it's inactive, as long as the titlebar and the borders make it instant-clear which window is the active one. I've been using dead-simple windowing systems like this for decades and never even have had to question their usability: that is good. period. Comparing to that, the past fifteen years or so have seen the artificial creation of all sorts of usability problems, that I attribute to having too many technical possibilities and a too-strong desire from the programmers to push brand new GPU FX onto the face of the users like if those were still kids in the 80's and 90's astonished by the awesomeness of each new hardware doubling the color-count, and also a will do be the inventor of something new, no matter if it's good or bad, as long as it's new. These usability errors, are very slowly being "fixed", i.e. ideas killed one after the other. The end users probably have the lead here, as they for the most part don't fancy graphics as much as the developers of desktop environments do, didn't put personal efforts into implementing them, and so were quicker to dismiss the bad ideas.

It may look like a capitulation to go back to what we already had 35 years ago, a time when a few brilliant people studied these concepts, with technical constraints imposing minimalism, and usage was flourishing with users not accustomed to anything like that. But there's nothing to be ashamed of. You people had to do, by yourself, that errant voyage through all kinds of esoteric graphics. Now that you're done, can you please come home, thanks.

In T10891#193267, @lavender wrote:

In T10891#193248, @ndavis wrote:

That might be because the colors are dark and the shadows are just more dark (black). I don't think there's anything that can be done about that and you should probably stick to light themes.

What if the shadow/blur used a color that contrasts the background?

In T10891#193232, @johan.boule wrote:

@lavender By inefficiency, I mean usability, being brain-friendly.

Breeze, particularly its dark variant, as a whole, is a theme that wants to wash-out any visible cue about what are the discrete elements on the screen, probably for debatable aesthetic reasons.

In T10891#193219, @johan.boule wrote:

FTR, the "Breeze" color palette proposed in Konsole is obviously not workable.
For the most obvious breakage: look at any manpage and you'll see (or won't see actually) that bright and dark text are indistinguishable!
You need to stick more closely to the standard, and only slightly adjust it.
Before you release a theme, check all combinations of colors to make sure there are distinguishable from each others (fg, bg, bright, dim).
I feel stupid for having to mention that, but, heck, I also feel that if I don't do it, you're gonna forget to check that again!

Note: the Breeze palette is not the only broken one amongst the default ones: there all are, except the "Linux" one and the "Black on White" and "White on Black" ones (which presumably are XTerm's default).

In T10891#193217, @johan.boule wrote:

TLDR: Where would you recommend me to go if Breeze is not my cup of tea?

In D12992#503172, @KonqiDragon wrote:

In D12992#269399, @abetts wrote:

I think we are trying hard to accommodate and the elements are not lending themselves to turn them into an E with some musical tones. I reviewed a few music sheets looking for commonalities. I feel also that the icon is busy, it is trying really hard to tell you that this app is about music. I feel we can simplify and provide other ideas.

Here is a proposal. Not final. I welcome feedback. The idea here is to show soundwaves instead.

The colors must match to HIG? I don't understand why KDE Applications have a logos in different styles. We do not have complete unify KDE style.

In T11124#193109, @mglb wrote:

The signal can be removed, as it is probably never used.

Turns out this is fixed in Qt 5.13: https://bugreports.qt.io/browse/QTBUG-71186.
Still, I think eventFilter should be used to support Qt < 5.13, at least for some time. The signal connection can be left here with ifdef for Qt 5.13 (and #else for eventFilter code to avoid double call) and mandatory comment.

In T11124#193090, @hpereiradacosta wrote:

In T11124#193005, @mglb wrote:

@ndavis Install event filter on qGuiApp, handle QEvent::ApplicationPaletteChange and call configurationChanged. Should work.

Hover/focus color change is not handled because there is QApplication::setPalette and QGuiApplication::setPalette. The former is used by KColorSchemeManager for changing color scheme and does not emit paletteChanged signal, which is used to detect the change in the style.

Mmm. Rather than installing event filter, which in some cases will be duplicated to the signal/slot handling, shouldn't we not fix the problem upstream, either in QApplication::setPalette, or in KColorShemeManager (which we own), to make sure that the paletteChanged signal is called ?
This way there would be only one code path in breeze, as well as in other styles (e.g. oxygen)

In T11124#193084, @mglb wrote:

qApp will work too (qGuiApp is qApp casted to its base class).

In Style class install (register) this as event filter: addEventFilter(qApp). qApp events will be received in Style::eventFilter(object, event), with object set to qApp. The case you're looking for is object == qApp and event->type() == QEvent::ApplicationPaletteChange.

The place where the mentioned signal is connected should be a good place to install event filter:
https://phabricator.kde.org/source/breeze/browse/ndavis%252Fhighlight/kstyle/breezestyle.cpp$201

Thanks for the tip, @mglb. Could you explain that a bit more? I'm not very familiar with Qt, I've just been figuring out things as I go and following existing patterns in the code. I grepped for qGuiApp and I didn't see it anywhere in the code of the Breeze repo.

Looks ready to land!

@hpereiradacosta I discovered a problem that must have existed since 2014.

Ha! I was just about to start working on this myself. Obviously, I agree that this should be done. However, we should take note of all of the instances where applications-internet is currently used so that we can switch apps that intentionally use the monochrome version over to another icon like internet-services or globe.

I think I do want the 32px version to not have the blue corners so that it is visually consistent with the smaller versions. Once that is done, I will accept this, as long as there aren't any issues with the colorscheme support.

In D22617#500953, @davidhurka wrote:

What does fill:currentColor mean, by the way?

Remove extra changes

In D22653#500427, @mbruchert wrote:

The blue corners are supposed to indicate that the QR-Code can be scanned.

In D22653#500471, @broulik wrote:

How about view-barcode-qr? then we could potentially have specific view-barcode-aztec and also a fallback to view-barcode

In D22617#500369, @davidhurka wrote:

Making the parts with background color transparent would be better, right? That would even work on systems which don’t access the stylesheet.

In D22617#500346, @davidhurka wrote:

By the way, the suggested stylesheet in https://community.kde.org/Guidelines_and_HOWTOs/Icon_Workflow_Tips#Breeze does not follow https://hig.kde.org/style/icon.html as far as I can understand it.

Hi! Thanks for the patch. There are few things I'd like you to change before I accept this.

In D22617#500168, @davidhurka wrote:

Other icons with fold in the bottom I could find:

• document-duplicate
• document-revert-symbolic[-rtl]
• kt-restore-defaults
• password-copy
• viewpdf
• xml-node-duplicate
• user-desktop-symbolic
• document-multiple
• folder-documents[-symbolic]
• emblem-documents-symbolic
  
  Most icons indeed have the fold at the top, especially Mimetypes icons look great. :)

In D22617#500031, @davidhurka wrote:

Makes sense, so I’m flipping snap-page now. Is that written down somewhere?

In D22647#500137, @ngraham wrote:

Right, I see that there's actually no regression. In principle, can you describe what a color scheme needs to do to avoid this situation?

In D22647#500117, @ngraham wrote:

Whoa, huge diff. All the more reason why we need to find a way to have all the icons use a single external stylesheet.

This will require documentation changes as well on https://hig.kde.org/style/icon.html and https://community.kde.org/Guidelines_and_HOWTOs/Icon_Workflow_Tips

As for the change itself, this is what happens when using the light color scheme:

Seems like this change just shifts the problem from Breeze Dark to regular Breeze.

I'll give the latest changes a proper review in a little while.

Change ViewFocus to ButtonFocus to match some elements in the Breeze desktop theme

Nice work!

In T11247#192423, @KonqiDragon wrote:

In T11247#192402, @ngraham wrote:

LXQt's biggest problem is that Plasma itself is now so lightweight that it infringes on LXQt's stated reason for existence. Accordingly, I don't really think it would make sense for LXQt to join KDE; rather, LXQt will probably die off naturally due to lack of a real niche it can sustainably inhabit, and hopefully we can recruit its refugee developers to KDE-land. I think they're already using some KDE Frameworks, right? If so, they're already gaining some familiarity with our technology stack. All we need to do is encourage that.

Maybe then add a lite/hight performance mode to Plasma in settings? In Windows there is something like this, but it doesn't work.

I think it looks pretty cool!

In T11124#191774, @hpereiradacosta wrote:

Finally there is still the issue of the HighlightedText foreground color in the palette. It is chosen to have high contrast against the highligh (=focus) color background. This is why it is white in the default color scheme. You should not change this, if you do not want to break other widget themes, or break text selection. If you want to manually lighten the focus/highlight color, by adding some translucency, so that you do not have to change the text color, you must make sure to use the QPalette::Text or QPalette::WindowText role, rather than modifying the palette's HighlightedText role. For monochrome icons there is the extra complication that the QIcon::Selected state will by default use the HighlightedText role for its main color. So what you would then need is to use the QIcon::Normal state instead of ::Selected, everywhere you do not want this color change to happen.

Looks good!

Looks good!

In D22493#496618, @broulik wrote:

Is it just me or does vertical alignment look off now? How does it affect the popup layout?

I'm willing to do work on this, but I'd like to say that I think there is room for some variety.

This is how the widget currently looks:

The latest version of this patch is better because it works well for people using the Breeze GTK theme with the Breeze colorscheme and it doesn't make the Breeze Dark GTK theme worse when combined with the Breeze Dark colorscheme. However, it does cause Breeze GTK to look odd when used with the Breeze Dark colorscheme:

Can I change the selection background color and use the selection color for the background of highlights? Then the regular highlight color could be used mainly for line highlights and outlines.

Abandoning because it can negatively affect other widget styles.

Abandoning because it can negatively affect other widget styles.

Thanks for the color overview. I'll avoid changing the highlighted text color in the colorscheme.

In T11124#191744, @ngraham wrote:

...Which reminds me, these QStyle changes are going to need to be replicated in qqc2-desktop-style too. And maybe also Kirigami in some places.

In T11124#191725, @hpereiradacosta wrote:

• For the record: toolbar buttons (or rather QToolButtons) can have focus too, when they are used outside of toolbars (and there are examples of such everywhere, for instance when you have an "open" button next to a text entry for selecting a file.

This causes a problem with Breeze and Breeze Dark when the titlebar is enabled.

In T10997#191697, @mglb wrote:

I think the symbol is too small for dashed line:

I'll see how it works with a little larger check mark

I need some help coming up with a consistent way of showing a distinct difference between mouse hover, keyboard focus and the sunken state. Here's what I know about how different widget types use these.