Here, this is a pixel perfect version.

These SVGs don't quite line up with the grid, which causes the inner part to have slightly blurry edges.

I've already said this to you in the VDG chat, but just to prevent confusion for other people, I'll repeat it here.

+1

In D23389#521086, @ngraham wrote:

Haven't had luck figuring out where this extra margin is coming from. given that it's already there, could we tackle that in a follow-up patch?

Seems like people still complain about the patch, so I'll go ahead and land this.

In D23444#518948, @ngraham wrote:

Are you sure this fixes the issue? I tried out the patch and deleted the removed files manually, but it didn't make a difference.

In D23415#519005, @zzag wrote:

I'm against renaming "smart" placement policy for couple reasons:
(a) it's been called like this since its inception, i.e. starting from late 1999
(b) "smart" is a catchy name, which is easy to memorize

In D23415#518850, @zzag wrote:

I don't think that renaming smart and maximizing placement policy is worth the trouble.

In D23415#518833, @zzag wrote:

In D23415#518815, @ndavis wrote:

I don't think a native English speaker would be confused by the wording, but if you think non-native English speakers might get confused, that's something worth considering.

Alright, let's approach this from other side. Why is "Maximized" preferred to "Maximizing?"

• Make 32px be 32px

In D23415#518506, @zzag wrote:

Renaming "Maximizing" to "Maximized"

"Maximizing" indicates that the placement policy maximizes clients.

"Maximized" indicates that the placement policy is maximized itself.

Take my words with a grain of salt because I hold a Ph.D degree in Broken English. I'd like to be corrected.

I think this looks pretty good, but why are the bottom margins on the first item different from the second item?

One way to avoid the localization problem would be to use the standard symbols for On/Off, 1/0. The only problem with that is a significant portion of the results for "on off symbols" on search engines are questions about which one is which. I also remember wondering why 0 was off as a kid when it made sense in my head that 0 should mean On because it looks like an O.

+1, especially changing "Smart"

In D23389#518275, @ngraham wrote:

In D23389#518269, @ndavis wrote:

Maybe we can add another line to the device item for the button to go on? Seems like it might just add visual bloat, but I can't actually think of a concrete reason why it would be bad. It could contain some small amount of useful info too, or maybe more controls from the hamburger menu.

Like this?

Maybe we can add another line to the device item for the button to go on? Seems like it might just add visual bloat, but I can't actually think of a concrete reason why it would be bad. It could contain some small amount of useful info too, or maybe more controls from the hamburger menu.

Maybe we should just keep the "Make Default" button in the hamburger menu? It's less visible, but we don't have much space and it's usually not as important as the device name and volume slider. We can keep the "Make Default" button in the audio KCM.

In D23389#518211, @ngraham wrote:

I'm also not a fan of icons-only buttons, because their meaning is ambiguous unless the icon is perfect. And we don't have a perfect icon here. We could try moving the button down to the next row:

Even then, in Russian (from Google Translate at least), the text is quite long:

I can add a note for translators that this string should be kept as short as possible.

Would moving the button to the second row work better? What do people think?

In T10891#195258, @onvitaik wrote:

In T10891#195205, @lavender wrote:

Sorry, you're correct, I meant readable. I can discern that it's a button but I can't read at a glance what the text says. Using your link it says fail for the text in the button: https://jxnblk.github.io/colorable/demos/text/?background=%233daee9&foreground=%23DAFFFF

I'm partial to noah's approach of using a lighter outline to help with discernment.

I think you picked the wrong colors. I meant this: https://jxnblk.github.io/colorable/demos/text/?background=%23428AAE&foreground=%23fcfcfc which gives AA Large. Not the best, but not a fail, either.

Not a fan of icon only buttons for uncommon tasks, but if saving space ever becomes absolutely necessary, we could use the star icon for "Make Default" instead of having text.

In D23389#517826, @anthonyfieroni wrote:

Why not it's a checkbox ? Make default looks big.

LGTM

Much better. There is only one thing left that I think should be done for 32 and 64 px. Rather than having a black "fb" for Breeze and and a white "fb" for Breeze Dark, use either white for both with a drop shadow under the "fb" or just black for both and no drop shadow. I only used different colors on the 16 and 22 px icons because they don't have a background.

Upon closer inspection, I found a few issues that need to be fixed.

Reduce the size of the SVGs by optimizing them with one of these tools: https://community.kde.org/Guidelines_and_HOWTOs/Icon_Workflow_Tips#SVG_optimization

rename svgs

undo rename

Let's abandon it for now. We can always come back if we change our minds.

Hmm. I was thinking about using the button background of the dropdown menu for something like this mockup:

In T11124#195731, @mglb wrote:

The line is used only in a sidebar, which is used mainly (or only?) in an application's configuration windows and system settings. I guess configuration windows are not maximized very often, so the shadow is not a problem.
System settings is probably maximized on smaller screens, but I don't think the shadow is a big problem - there is regular blue background as a main highlight indicator.

I also think that using toggle for search makes more sense. It would be nice to have a general pattern of using toggle buttons in the toolbar for things that can be opened and closed, especially when they're activated via the toolbar in the first place.

Considering the changes were already agreed upon before I made this diff, it seem safe to land without further review.

In T11124#195688, @alexde wrote:

There's a white line, which contains a blue line under the "about" tab.

1. Has that been changed recently, because under Plasma 5.16.4 it looks different:
   
2. Is the white line necessary at all? When I now checked Breeze light, it found that the white line is there as well but hardly visible at all:
   
   
   
   Personally, I would drop it, as having two lines or a bicolor line looks kind of wrong to me.

Anyone want to accept this?

I think I'm going to continue using the outline/sideline+fainter background style. With simple solid highlights, there is a contrast issue where the highlight color either doesn't contrast well with the text or doesn't contrast well with the window background. With a strong highlight outline/sideline and weaker highlight background, we can have good text contrast and good window background contrast.

Alright, problem fixed.

In D23169#513046, @hpereiradacosta wrote:

Hi Noah
Thanks for the patch, however, it is not the right fix to the issue. If you use a light color scheme (like the default breeze), you will see that the shadow below the part of the button that corresponds to the arrow is darker than below the rest of the button. This is because the frame is actually rendered twice.

Now, the bug you try to fix is real, and as I was 100% sure that it was not there in the past, I used git bisect to track it down to this commit:

32d8b02880a237e6de415861500a018a5cd09781

The corresponding diff contains
@@ -5988,7 +5988,6 @@ namespace Breeze

// frame
if( toolButtonOption->subControls & SC_ToolButton )
{

• copy.rect = buttonRect; if( inTabBar ) drawTabBarPanelButtonToolPrimitive( &copy, painter, widget ); else drawPrimitive( PE_PanelButtonTool, &copy, painter, widget); }
  
  Which is what causes the issue. Could you revert this commit, and push instead the proper fix that I will post in another comment ?
  
  Alternatively, I can do it myself. Note that your changes on the separator position is legit, but should be a different patch

In D23170#512753, @ngraham wrote:

Sounds like you know more than me. Still, the top one is inside a no-KDE4 ifdef, if I'm reading the code right.

I thought the hex values were used because it's also supposed to be possible to compile Breeze for Qt 4? I remember reading that Qt 4 needs hex numbers for some reason.

Add event filter for Qt < 5.13

In D23170#512391, @ngraham wrote:

In D23170#512292, @ndavis wrote:

How likely is it for distros using Qt < 5.13 to receive an update to Breeze that isn't a backport?

Do you mean to say that this is fixed already in Qt 5.13?

How likely is it for distros using Qt < 5.13 to receive an update to Breeze that isn't a backport?

In D23075#512110, @elvisangelaccio wrote:

Wow, this is quite a radical change :)

I'm not against changing the default layout, but we should be 100% sure to get it right. It would be very annoying if we have to change it again in six months because people didn't like it.

My comments after a quick try:

1. I don't think we should add the "Go Up" button because you can already achieve the same action by using the url navigator buttons.

We don't strictly adhere to outline or filled style (for better or worse), sometimes making use of both styles in the same icon (e.g., view-list-icons). I think the general idea is that we normally use the line/outline style unless that puts the designer at a disadvantage. Icons can look messy with the outline style sometimes.

In T11124#195358, @mglb wrote:

List view/sidebar highlight: why the vertical bright line is on right (internal) side? Wouldn't it look better on left (outside)?

In D23116#511480, @trickyricky26 wrote:

I thought about that, too, and while the red used in the icon is exactly NegativeText, the blue in the current icon is darker and has a less vibrant hue than ButtonFocus, so I'm not quite comfortable with using that for the blue color. Do we have this darker blue as a CSS color that we can use in this way? I see this dark blue is also used in the channelmixer icon, which has its colors hardcoded as well. I also don't think it would make sense to only use stylesheet colors for only one of these two colors.

Not having id="current-color-scheme" causes stylesheets to not work correctly. Other than that, +1.

In D23075#510697, @GB_2 wrote:

This is my final proposal with a category structure.

In D23075#510680, @GB_2 wrote:

In D23075#510675, @ndavis wrote:

In D23075#510674, @GB_2 wrote:

Is this better?

I think the view mode buttons should be replaced by the single View Mode menu button. Unlabelled icons are a bad idea unless the symbol is very common and very distinct. I don't think it's reasonable to expect people to understand the compact mode and icon mode icons without looking at the tooltip.

I think the Sort By button should also be on the left.

If a Create New button is also added after more discussion, I think it should also be on the left.

Did you read my comments about the view mode button?

In D23075#510674, @GB_2 wrote:

Is this better?

In D23075#510022, @felixernst wrote:

In D23075#509940, @ndavis wrote:

Make sure the default layout doesn't look lopsided when the application menu is enabled instead of the control button.

It does look kinda lopsided but I am not sure if it is worth it to change the default look because of that.

In D23075#510484, @ngraham wrote:

They are enabled by default.