Just in case you misunderstood me, when I said create the corners from rounded rectangles, I meant create the rounded rectangle and cut off the parts you don't need so that you're left with corners that you can place however you need. If you're not aware of it, check out Inkscape's Path menu. It has a ton of useful stuff for sculpting shapes.

I'll trust your judgement on the masks and corners. If there's a problem, it can be patched. I know this stuff can be super janky at times.

I noticed a few things.

For some reason, the corners of the checkbox indicator don't overlap perfectly with the corners of the base checkbox, even though the corners are exactly the same in the SVGs.

This patch has a few problems and some things to consider.

In D24706#596541, @ahiemstra wrote:

KScreen uses QML, so it may well be that the buttons were rotated using QML's rotation property, which does rotate the frame, since that's rendered by qqc2-desktop-style's StyleItem as a sub-part of the button.

In D26739#596355, @ngraham wrote:

Yeah. I don't disagree. But if I just ensure that the highlight effect is the highest item, the borders still get obscured by the player controls and album art. And the rounded corners of the highlight leave a pixel or two of the art to escape the bounds too.

Not a fan of the inner frame. We should avoid making frames within frames. I don't think it really needs changing, except that the sides cover the blue border frame.

In D24706#595796, @cfeck wrote:

If application developers need a rotated button, they need to rotate only the contents, not the frame.

TBH, the current way control shadows are rendered seems kind of wrong anyway. The shadow is rendered within the button, so when you rotate a button, the shadow gets rotated as well.

I think I'm going to need bigger, fancier shadows to get a good pressed movement (besides changing background color) with the diagonal movement removed.

In D24706#595764, @ngraham wrote:

Thanks Noah.

So you're the boss after all (as the de- facto Breeze maintainer now), and I think we should follow your lead design-wise. But it might also be interesting to have a discussion about what we want this to accomplish.

Personally here's my wishlist:

1. Make it much more visually obvious which button is the default button
2. Make the focused state look less like what most people would assume is the appearance for the default button
3. Avoid making the focused state look too subtle
4. Make the pressed state look more "pressed"
   
   I think this patch does #3 and #4, but not #1 or #2. However it's possible that the focus style you've chosen will be just fine once the selection effects look like this everywhere for consistency, and if the default button gets a stronger look.

There were some conflicts, so this isn't exactly how it was before.

Rebase

Vertical scrollbar taking the corner without the column header change:

In D26655#595381, @hpereiradacosta wrote:

As a side note: I have been using this code for a couple of days now, and while I think the separator looks well for vertical scrollbars, when you have both vertical and horizontal, ... this will need some getting used to.
See:

This is with a thin handle, but having the thick one does not really improve. The view looks like a frame inside a frame, first one being off-centered.
I have no clue how this can be improved

I noticed that when hovering on the scrollbar border, while the view area is not focused, the scrollbar handle is light gray (Breeze Dark, dark gray for Breeze) instead of blue. Moving the mouse just slightly more to the right turns the scrollbar handle blue.

In D26655#595033, @mart wrote:

moving the points half a pixel in renderArrow seems to fix it, but it may have sideeffects for arrows used in other places..

+1 to this change.

In D26649#593825, @broulik wrote:

So you can't tab around to end up focusing the text field?

Fix formatting

After this patch, should I remove isSelectedItem()? It's currently unused.

In D26572#593511, @hpereiradacosta wrote:

Otherwise, it should be Window Background. Doing it that way would preserve the original look in most cases.

This would lead to some regression (I think) for unchecked checkboxes in lists. (because of window background being used).

What I meant is that I did not change the color of the checkbox background in this patch. I only made it so that the background would always be rendered.

In D26572#593379, @hpereiradacosta wrote:

in more detail: imagine a color scheme where window background is black, window text is white, view background is white view text is black.
you will get a white square on a white background for unchecked checkbox ...
I would really revert this part of the change

Oh, I should have brought this up before landing, but any opinions about always using QPalette::Base (View Background) for the background color? I asked on the VDG channel and people seemed to be unanimously in favor of using View Background as the background color.

Since it's @cfeck's bug report, I'll add him to the subscribers.

In D26271#593013, @gvgeo wrote:

Found this request to display the name of the stream https://bugs.kde.org/show_bug.cgi?id=409453 .
Which was done, but remove here. Maybe should leave it too?
With a quick check, not many applications have this information.

Since this improves checkbox visibility when rendered over images, should we or should we not do this? Is there a way to detect when a checkbox is rendered over an image? Is the added complexity of making all these exceptions better than always rendering the background?

In D26595#592368, @ngraham wrote:

Hmm, at normal size, the 8, 16, and 22px versions look too busy to me.:

In D26587#592088, @broulik wrote:

Hmm this makes inactive tabs even harder to spot than already :/

These are the 2 Zephyr styles I found. They're not very popular and haven't been updated since 2015. I guess it wouldn't hurt to use Zephyr.
https://store.kde.org/p/1005426/
https://store.kde.org/p/1005427/

I think this is fine.

remove .clangd/

Icons in the desktop theme that are made to replace icons in the icon theme need to be kept up to date with the icon theme. I'm accepting this as it is, but if @davidre thinks we should continue to support the use of the nepomuk icon name, then include both in the desktop theme. If this seems inelegant, that's because comprehensive icon support is not very pretty, technically. breeze-icons is filled with tons of symlinks for compatibility and there's really nothing we can do about it.

In D25814#591053, @ngraham wrote:

I wonder if a path forward is to move this option into Breeze itself and keep it out of the color scheme. We would add an option for "dark separators when using a dark color scheme" in the super hidden Breeze settings window.

In T12308#217196, @ngraham wrote:

So are we officially abandoning the idea of moving the Breadbcrumbs/URL Navigator into the toolbar? Shall we close T11663?

+1 to not using overlay scrollbars on desktop

I don't think we should change the icon style to be more rounded. I don't think it would be worth the time and effort required. I also don't like the Breeze Round Corners theme. You can't just round the corners and call it a finished job. Many of those objects depicted have ruined proportions and jagged edges from being clipped.

This is specifically about a new repo for the new version of the Breeze QStyle and maybe the KDecoration too, which are currently in the breeze repo.

+1

In T12308#216790, @ngraham wrote:

I agree, quite nice.

I wonder if we should make the status bar span the entire bottom of the window, not just the view area. And maybe we should keep it with a gray background. That way there would be two gray bars at the top and bottom of the window anchoring everything in the middle.

What do you think?

Zephyr is super appropriate—a breeze from the west—but the name reminds me of generic military FPS games for some reason. Also what @cblack said.

In T12308#216716, @ngraham wrote:

If we leave it where it is, what I'd like to do is make it more of a distinct element so that it doesn't blend into the toolbar like it does right now. I think @manueljlin had some mockups showing that which looked pretty good.

In T12308#216709, @elvisangelaccio wrote:

It seems to me that moving the url navigator to the toolbar creates more problems than it solves, because of split views.

What for? Just to be similar to other filemanagers? How many of them have split views anyway?

I'd like to avoid association with anything violent or negative.

In D26271#588570, @gvgeo wrote:

It is a theme problem. Breeze light also has problem.
Widgets take color from Plasma Style. While in applications are fine.
I checked with this widget to compare.

Why do the unchecked radiobuttons have a dark outline in your screenshot?

We could also come up with a completely different name.

What should we call the new version of Breeze so we can use it as the repo name? I thought about Breeze 2 or Breeze 6, but those seem like they might cause confusion for users, especially if distros continue to package the old version of Breeze along side the new version.

The top part looks a bit too flat and wide. There's also nothing attaching it to the body, so it looks like it's floating.

Make sure you copy to breeze dark as well

In T11052#216506, @ngraham wrote:

@ndavis by "this" do you mean the whole accent color idea? If so, I don't really agree, sorry. No matter how easy we make it to edit color schemes, doing so will still be a much more heavyweight experience and a less discoverable feature compared to a simple color picker exposed at the top level of the KCM that overrides the color scheme's highlight color. The idea of an accent color feature is basically saying, "this is the color in the current color that the user is most likely to want to change to suit their personal aesthetic preferences, so let's make it really really easy to do so."

For 16/22px, the current way is acceptable.

I don't see a great benefit to implementing this. While the addition of an accent color feature and an improved color scheme editor are not mutually exclusive, I think that an easier color scheme editor would significantly reduce the need for an accent color feature. This is yet another system on top of the color scheme system, on top of the Qt palette system.

In T12488#216445, @ngraham wrote:

The downside of course is that it could take years to roll out the new theme if we make it a separate fork/codebase. If we do go that route, I'd like to try for an aggressive timetable and not get stuck in analysis paralysis and shooting for absolute perfection.

In T12488#216428, @cblack wrote:

Are you going to open a sysadmin ticket about this?

Actually, this does have some negative effects on the appearance.

This works for me. Is it possible to enforce a minimum font size equal to either the general or small font settings?