This was a proposal for a browser rebrand that I posted on the Mozilla Wiki about a decade ago but I don't think many people saw it and too many were emotionally attached to the fox. Just also posting it here in case you wanted to use it. I knocked it up in MS Paint in about 10 minutes, so it's just for the concept and obviously not a polished final design or anything. Could change the colours if orange was too Firefox-like.

One other important thing that hasn't been mentioned is that any new theming engine should be HiDPI aware. Currently, with regards to Window Decorations, I have not found a single Aurorae window decoration which renders flawlessly without adjustment across multiple DPIs.

I remember seeing someone had written some excellent scripts to automatically generate the GTK theming from the current Plasma settings -- I cannot find this again, but it looked impressive, and for some unfathomable reason I think (?) it had been rejected.

I haven't heard of this thing, so please provide a link if you can find one. If it was rejected, it was probably because it was too slow or it depended on something that wasn't stable (guaranteed not to change). As I said, I haven't heard of it, so I could be wrong.

I think any new theming engine needs to universally apply its theme (particularly the window decorations and in-app decorations for dockable controls) to GTK as well as Qt. Too many major applications are GTK and not going away. The current theme engine is next to useless as GTK apps aren't affected by changing the standard theme.

In T10891#224533, @niccolove wrote:

On a different note, how do you feel about increasing the radius of the titlebar? I think it might make the window look prettier.

In D28356#636593, @ndavis wrote:

KDE4 was unpopular because it was heavier and buggier, not because the titlebar buttons were different. I didn't like KDE back then either (I mainly used GNOME 2 and Unity), but I did like the window decorations. I think the current buttons are clear enough as they are and any change would be more of a branding change than a usability change. KDE 1 copied a lot from CDE, including the titlebar buttons. Windows 3.1 is different enough that we're pretty obviously not copying it. We also have a maximized symbol, unlike Windows 3.1.

I went ahead and made an Aurorae version of this just to get a feel for how much I could theme. Overall, I am disappointed with Aurorae as Plasma is not as easily customizable as would first meet the eye. Aurorae alone will not let you customize the titlebar buttons as comprehensively as one would initially think:

• The in-application Application Style also needs titlebar-like button icons as provided in Breeze kstyle (as menitoned by David above)
• Aurorae does not obey system colour settings, especially for the titlebar itself
• GTK applications which use the client side window decorations in the titlebar (e.g. Gedit) still require updated SVG files
• GTK applications such as Chromium require updated .png files (generated with a Python script using Cairo libraries)
• The icon theme also needs updated as the titlebar buttons are also referenced in other places throughout the UI such as in application menus, in right-click menus and notification pop-ups.

It has been part of the default kde look for many years (for all of oxygen and breeze) and forms a core part of our design brand. It's something where you can spot breeze on the first look. It seems MacOS can get away with colored circles without people complaining about usability.

In D28356#636309, @cblack wrote:

IMO, the maximise and minimise buttons are a step backwards from the current decorations in terms of legibility and aesthetics.
Minimise especially, considering that a square has no meaning at all. Maximise is also less aesthetically pleasing than the current one IMO.

However, I like the new keep below and keep above icons.

In D28087#628873, @ngraham wrote:

Nice. Can we have an email address so the patch gets landed with correct authorship information?

In D27938#624385, @ngraham wrote:

A small bug is also fixed in kdecoration/config/breezeconfigwidget.cpp whereby the "Draw a circle around close button" setting does not reset to Defaults properly.

Would you mind extracting this into its own patch and submitting it separately? Sounds like a good fix, regardless of whether or not this patch gets merged in its current form or in another form. In general it's best to have each patch/commit do only one thing and not combine new features and bugfixes.

In D27938#624385, @ngraham wrote:

A small bug is also fixed in kdecoration/config/breezeconfigwidget.cpp whereby the "Draw a circle around close button" setting does not reset to Defaults properly.

Would you mind extracting this into its own patch and submitting it separately? Sounds like a good fix, regardless of whether or not this patch gets merged in its current form or in another form. In general it's best to have each patch/commit do only one thing and not combine new features and bugfixes.

In D27938#624382, @ngraham wrote:

Can you add a bit more information about what your goal is here? You're adding different icon styles for the titlebar buttons that you can use while still using the Breeze window decoration theme? Before-and-after screenshots would help too. See also https://community.kde.org/Infrastructure/Phabricator#Include_some_screenshots

Hi Nate. Yes, the changes allow you to have different sets of icon styles for the titlebar buttons, while still keeping the overall Breeze style. I have updated the summary. The motivation to add it was mainly to add the 'Classic' button icon style, while also preserving the 'Oxygen' style of button icons for those who like it. I have added screenshots to the summary, and will maybe make another video to show it tomorrow.

Diff now submitted at: https://phabricator.kde.org/D27938

In T12441#222663, @ngraham wrote:

All right, I'll put together a patch for a thickened bottom panel with an IOTM on it and some pre-pinned apps. We can discuss moving it the left (or not) later, if it lands. :)

In T12441#222715, @The-Feren-OS-Dev wrote:

Some more things that may or may not have already been mentioned, given that some of us are considering the idea of moving the hotcorner to the bottom since it'd get in the way of the panel up top:

• Bottom-right hotcorner: Gets in the way of scrollbars...? (also mouse resting area)
• Bottom-left hotcorner: Gets in the way of Show Desktop (and the Panel Toolbox in Global Edit Mode)
• Bottom-center hotcorner: You'd, er, have to implement that first.

In T12441#220104, @ngraham wrote:

IIRC @hein was working on some backend work that would allow for a mode where clicking on a grouped entry would move the windows of that app to the front one by one without using the Present Windows effect. This is how it's handled by the macOS Dock and the popular Dash To Dock GNOME extension (a fork of which Ubuntu is now shipping by default). I really like that behavior compared to showing the Present Windows effect.

The position of my panel depends on my display aspect ratio. On a 16:10 or taller screen (which I prefer) I place it on the bottom. In this scenario I think it makes more sense to have the labels as it's more intuitive with more information and allows for a very thin panel, yet still with large clickable areas. It's a waste of space to have a thick panel on the bottom to allow large clickable icons only (like Windows 7 default), as most of it is usually blank; this useless space seems to be why Microsoft added the useless search box in Windows 10.

I don't think the current Plasma 5 titlebar looks ugly at all (well, except for the confusing Windows 3-style buttons, but that is a different story which I have a proposal for here (update to that coming)). To me, rather the proposed changes to the titlebar here make the windows look rather bland and dull. I don't see any reason why usability should be sacrificed like this for the sake of a fashion change. It is much more important to make the active window stand out, and also make it clear that there is an area which you can definitely drag.