In T10891#234000, @niccolove wrote:

+1/-1? Should I make a patch for it? Any alternative designs that don't require additional elements that link to the widget?

In T12441#230507, @KonqiDragon wrote:

In this task offers to fit everything in vertical panel, that looks ugly if compared it with Ubuntu, especially system tray and time/date.

I'm not too keen on that mockup. It looks like the tab and the tab contents are no longer connected.

In T12839#223897, @The-Feren-OS-Dev wrote:

While we're at it, it'd be good to finally have one text size for the panel overall. That includes the font size for Digital Clock (all modes), Task Manager, etc. (only the parts of those applets that have text on the panel itself)

I'm incredibly late, but the problem, as I see it, with it looking "fairly light" is that all the button and frame borders are lighter than the background and almost as light as the text. These color changes just exacerbate this issue.

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?

On a related note, is it possible to also make the header/title font size smaller, matching the other text close to buttons? Right now, pretty much all the headers across Plasma/Breeze look very overbearing due to how big they are. It's like they want you to look at them more than the contents of the window.

In T11665#201381, @ngraham wrote:

Please feel free to open it! Or I can, if you'd prefer not to.

Tooltips don't need to immediately pop up, of course, like most tooltips nowadays. They would not hide your stuff unless you kept hovering over an item for long enough.

Would it be possible to drop the vertical text (both bottom-to-top and top-to-bottom) on the sidebar, and instead just use buttons with tooltips? From a UX standpoint, vertical text can be a big negative to users, as you're possibly making them tilt their heads to read the text better. It can also make the UI feel a bit inconsistent by being the only place(s) where text is not horizontal.

In T11665#201378, @ngraham wrote:

In T11665#201377, @mglb wrote:

Adding border to all toolbar buttons will be super heavy in cases where there is more than a few buttons.
To do changes like this I think we should separate concept of classic toolbars (few toolbars, each with many buttons/controls) and modern "widgets row" (few controls visually aligned with window/content). Or just use QToolButtons with disabled autoRaise to get the border on them.

Yeah, I agree that this would be totally inappropriate for e.g. LibreOffice or FreeCAD with have huge toolbars stuffed to the gills with unlabeled toolbuttons (whether it's ever a good idea to do this in the first place is left for another discussion...). I was thinking about our apps, really.

In T11665#201143, @ngraham wrote:

In T11665#201118, @onvitaik wrote:

I'm afraid it might look out of place either way, though, as the other buttons have neither frames nor different background colors.

That's the whole point. :) Segmented controls should look different, because they are different. Different things should look different.

Personally, I think the different background looks better than a frame. I'm afraid it might look out of place either way, though, as the other buttons have neither frames nor different background colors.

In T10891#196454, @ndavis wrote:

Actually, it is a fail for typical usage. AA Large (3:1) means it meets the minimum requirement for large text (at least 18pt or 14pt bold) like page headers, not small text like lists and labels. The minimum for small text is AA Contrast (4.5:1).

In T11093#199130, @ndavis wrote:

In general, we use labels for everything that isn't a common control. Common controls are things like forward, back, undo, redo, etc. If a label isn't used, the function of the button needs to be pretty obvious.

I think it's more important to be consistent in logic than uniform in appearance. There is a lot of overlap between the two, but there are cases where aiming for a uniform appearance leads to inflexible designs that make some UIs less usable.

Can I also suggest making the tabs occupy the full width of the area available (sort of like Kate)? It minimizes the unused space and keeps everything in a nice rectangle:

Here's my 2 cents:

Might not be the most appropriate place or time to ask this, but considering how the KCM title is shown on the title bar and on the side bar, isn't it unnecessary to have a header that pretty much says the same thing a third time?

I think Breeze in general could really use some separators as a way to indicate one area is not attached to the other. Take Dolphin for example: The address area's background color is the same color as the sidebar's background, and with no visual separator, it looks like the two areas are directly linked. It looks strange.

In T11124#195687, @ndavis wrote:

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.

While I'm not dismissing the possibility that the new style is more distracting, I don't understand what you mean by that. The new style draws more attention to the content surrounded by the outline or in the direction of the sideline.

Just thought I'd drop my own thoughts here. Personally, I've never been a fan of how Highlights have a different border and a background color. I think that it should just be a solid color for all cases (except perhaps for buttons and the bigger elements), just so we don't have multiple types of highlights.

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.

In T10891#194989, @lavender wrote:

The first highlighted pushbutton (where the cursor is) is less visible in your version than noah's due to the contrast. And the radiobuttons has weird artifacts but maybe that's a compression thing.

In T10891#194762, @ndavis wrote:

So what do you think about these highlight/selection/hover/focus colors? I chose them by taking Plasma Blue (#3daee9) from the KDE HIG and adjusting the brightness with HSLuv.org. The selection background color is 1/2 the brightness and the hover background is 2/3. I don't really know how to pick colors, so I'm taking a somewhat conservative approach where new colors are at least somewhat based on existing ones.
<image>

In T10891#194750, @ndavis wrote:

How/why did you pick those colors? Is there a method or formula that you follow?

Here's another set of dark theme mockups (and some miscellaneous modifications to tabs, sidebars, title bars) :

On the topic of the dark theme: I think it currently has too much contrast. Most elements you see have a dark background with light text and light borders, which makes you (or in this case, me?) focus almost as much on the borders as their content. Making the borders more subdued, giving the tab area a lighter color to make up for it, making the buttons lighter than their borders, and using more pastel colors could be a start. Here's a quick edit of @ndavis 's screenshot/mockup as an example:

In T10891#186101, @mglb wrote:

Centered title is awesome!

However, I see two problems:

• Non-editable combo boxes look like editable combo boxes. It is also possible to confuse buttons and line edits with centered text. The latter is really problematic - line edit can be clicked without any consequences, buttons can't.
• Instantly applied settings:
  • Changing some settings is slow. Some have inconvenient side effects not easy to fix without hacks. E.g. window flags change causes the window to be hidden and shown, what resets some WM properties (desktop, minimized state under X with thumbnails turned on, etc).
  • Would need a lot of work - all applications would need to be adjusted for it. While not really a problem in itself, it would need its own task :)
  • There should be something to undo the changes.

Nice to see it's well-received!

Since I saw those crude mockups, I've been changing it with the suggestions I wanted to make plus others. It takes some pages taken from how other DEs do their things and some of my own preferences, while at least still trying to not deviate too wildly from the Plasma look. I've also combined it with some suggested changes to the current system settings application.