I don’t think that there’s any need. It was recently improved substantially.
In the real world that has not happened.
It’s important to distinguish between style and function/layout
I already know the difference between function and style, but it still doesn’t justify rejecting being equivalent to Windows 11.
We don’t want to be equivalent to Windows 11; we want to preserve our own style and branding. If we look adopt the Windows 11 styling and/or design philosophy, then we’ll be perceived even more as just a cheap clone of Windows 11. Merge requests to go in this direction would be rejected.
If you personally prefer a Windows 11 style, well, that’s why we have theming. 
Got to say, I use Breeze on my main machine, and windows 11 on my work-provided laptop. I much prefer the look of my main machine.
Diccionario de la Real Academia Española.
Dictionary of the Royal Spanish Academy
be equivalent
From the lat. aequivalēre.
conjug. c. to worth.
For sure, the day Plasma start to looks like Windows, I’ll start to look for something else 
Grum999
Removing the 45° shadows on colorful icons
Is the idea to just remove them altogether, or is there a new, preferred approach?
Broadly overhauling colorful icons in general
Is there documentation I can read on what sort of changes need / want to be made? And when submitting changes, is it just a matter of submitting a PR for each icon, or would it be best to submit a PR for multiple revised icons at once?
At risk of feeding the troll here, you haven’t really provided a rubric by which we can judge whether Breeze styling is equivalent to Fluent. What design goals aren’t being met by Breeze right now? In what ways is Breeze less accessible or usable? What does Fluent design accomplish that Breeze does not?
Without this information, it just seems like you personally prefer Fluent.
Nathan, if you want to help out with this, that would be amazing. We don’t really have a ton of concrete plans so far–just abstract desires. So you could help to define the new designs, too. In general we would want to re-do all icons of a specific category all at once; one MR for all action icons, one MR for Places icons, etc. I would welcome you to discuss it on the VDG chatroom so we can coodrinate; see Get Involved/design - KDE Community Wiki.
It never occurred to me to do so, but worth having a look when I’m not supposed to be working 
In general we’re in a hybrid state right now.
Throughout our QtQuick-based apps and Plasma, and also in Many QtWidgets-based apps, we deliberately use this left/right aligned FormLayout Style.
The QtQuick FormLayout implementation also supports putting labels above controls and having all of them be left-aligned. It’s a trivial change.
The QtWidgets implementation does not support this.
In addition, there is a new settings style being adopted throughout many mobile-focused QtQuick apps using a new component called MobileForm. It looks like this:
It’s unclear whether this is a style we will be adopting throughout all QtQuick-based config windows. Also, there is no QtWidgets version, so adoption in QtWidgets-based apps is currently not possible.
What we need to do is decide what we’re going to use and adopt it universally. And ideally, create an implementation that is declarative so that we de-couple settings from visual implementation and then we can change the visual implementation easily. See What's the future of the mobile settings components? (#14) · Issues · Teams / KDE Visual Design Group / Issues · GitLab.
I’ll pop my head in!
And perhaps off-topic, but I’ve got to say though, I wish this language were a bit different on the design page haha:
In a highly technical field like programming, it’s easy to encounter the limits of your expertise. This is more difficult in subjective fields like art and design
IMHO, as someone who is both a programmer and a designer, I’d say that design is no more subjective than programming. Both are creative problem-solving processes, and good design decisions should always be grounded in usability research, accessibility, psychology, etc. Someone could debate a pattern in a program as much as they could an interface design, or even a leaflet. Art is an entirely different beast. You certainly do see, however, many designers who really just wish they could have been artists who try to create art where an actual design based on tangible goals is needed. And certainly, people who just learn the tools are subject to the Dunning-Kruger effect. I imagine that’s what the above sentence is trying to address.
Yes, I think you’re right about this, and lumping art and design together in that sentence was probably a mistake. Feel free to edit it; it’s a wiki after all!
If you want Windows style, we already have it 
Blue screen of death included? Otherwise unusable /s
It’s too inconsistent to want to use, though, since there isn’t a KWin Window Decorations counterpart. I tried to get two old people to use it since I expected they’d be more familiar with it, but they said that learning Breeze was actually easier since it provided more visual consistency.
I’m obviously paraphrasing.
It’s not so hard to make a single theme for a single toolkit in isolation for your own purposes, but you seem to have no idea how hard it is to write a new theme for all existing apps. I really do mean all apps, which means Qt Widgets (QStyle), Qt Quick Controls, GTK3 and GTK4 (thankfully no more important apps use GTK2). That’s actually 4 theme just to make one new theme. This also includes 3rd party apps that may behave in surprising ways, depending on behavior in the Fusion, Windows Vista (used on all Windows versions since Vista) or MacOS QStyles, or the way a particular property in a Qt QQC2 style was set. We’re a platform, so we have to do this. There are endless things that you will never think of unless you spend a whole year pouring over Qt source code and KDE code of the past and present to ensure you’re not likely to break existing software via subtle behavior changes and that’s just for the Qt based themes. I don’t know GTK theming very well, so I can’t say much about that, but I know it has its own share of difficulties from the “Don’t Theme My App” campaign aimed at distros shipping app breaking themes. Even when you think you’ve done a good job, there will be things you missed. Yes, we are capable of doing multiple things at once, but we’re already doing multiple things at once. We are choosing not to make a new theme because it would be one more giant high risk task on top of the other tasks and the current theme is good enough. Maybe when we decide to make a new theme, we will have a new unified theming engine to go with it, but that’s currently just a dream. We probably still won’t try to make Plasma look just like $OTHER_PLATFORM though.
This is much easier to parse
If it’s so easy make it yourself.
I can do it from this Twitter:
https://twitter.com/kdecommunity
117400 followers
May I?
While I think there’s no such thing as a timeless design and that it’s true that people psychologically see projects that don’t follow the latest design trends as old and outdated, I don’t think it’s prudent to completely revamp Breeze during the transition to Plasma 6. Yeah, revamping the theme from time to time does bring psychological and branding-related benefits. It’s a known fact that people make their purchase/consumption decisions based on visuals a lot of the time. However, Plasma cannot afford to repeat the mistakes that plagued the transition from KDE 3 to 4 and from Plasma 4 to 5. Those transitions caused a big amount of bugs and performance problems and tarnished Plasma’s reputation forever. Even today some people still assume Plasma is heavy and buggy.
The less things get changed, the smother the transition will be. I’m totally in favor of Plasma 6 taking two or even three release cycles to be released. For the same reason, I believe that any visual change should be implemented very gradually or at least come in future releases after Plasma 6.0.
