Huh, I was waiting for @hein :) oh well, here it is - C icon with cleaned up source

Todo (user-visible):

• add "mouse down" visual state
• basic color fixes:
  • check boxes color in tree view changes when the widget is focused/unfocused. This does not happen in list view.
  • draw distinguishable frame around selected check box in menus/lists. Not treating State_Select as focus/mouseOver will fix this.
• clean/simplify animations

Not much, but I'm going to finish at least user-visible things in next 2 weeks.

Right now you can't even draw this connection nicely using QStyle.

What do you mean? Qt accepts CSS to style elements so I'm pretty sure it's possible to draw some very nice custom elements with Qt.

In T11662#211546, @ndavis wrote:

In T11662#211545, @mglb wrote:

I understand, but I was referring to following mockup, where the button has input field background, so I perceive it as in-field icon like "clear" with separator :)

Connected button outside is technically OK, but... not in Breeze style. So either we change it everywhere, or add little spacing between input field and button. Right now you can't even draw this connection nicely using QStyle.

Most of the styling on that widget is custom right now, so it wouldn't be any worse if we kept it custom.

I understand, but I was referring to following mockup, where the button has input field background, so I perceive it as in-field icon like "clear" with separator :)

In T11662#211062, @ngraham wrote:

I'm very much in favor of having a dedicated button to enter edit mode.

• Don't do straight vertical separators + arrow down - it looks like favorites list or something, not ordered hierarchy.
• > doesn't make sense when placed after directory name - it means something like "next directory is...", and clicking it should modify directory on the right of the arrow.
• Don't highlight arrow and label like it is a single thing - it is not. Clicking label has different action than clicking arrow.
• Don't make last item (current directory) clickable/highlightable - clicking it does nothing.

In T11662#209175, @joricke wrote:

The biggest problem that I see with the breadcrumbs receiving a new coat of paint with pointy or slanted lines would be the fact that it's a UI element that doesn't exist in vanilla KDE anywhere else in that form. At least I can't think of where it shows up, but please correct me if that is wrong. Taking Gestalt theory into consideration, this might be bad UX as it exposes users to new elements that are unique to that one location.

What does this arrow-down near desktoptheme do?

In T11662#209097, @pedrogomes1698 wrote:

Isn't it cleaner to just have straight lines?

If so, Kirigami can be modified to work as needed.

Default text color and this new background blended with white still has good contrast, but it doesn't look so good when colored text is used (not that it looks perfect now).
Also, please consider how it looks with transparency but without blur (as it does not work everywhere). It can be distracting.
Konsole is sometimes used for hours for looking at text, so it have to be readable by default.

Why (assuming it would be possible to disable it)?
Example use case: there is optional feature in Konsole which randomly adjusts foreground and background colors in each session (hue and saturation; perceived lightness is kept constant). It helps with finding specific window/session, as it is easier to find window tinted to specific color than looking at content/title (when it is similar), especially when window is scaled down (present windows effect). It could be nice to extend this adjustment to whole window (and titlebar), of course with user consent.
We make titlebars blended with window for consistency, and because it looks nice. Does it make sense to prevent similar consistency with application which uses different colors (e.g. web browser)?

Application Style

Color scheme issue. Highlight background color is used. I could change it to something like background color of selected item in unfocused sidebar, but then it won't look that good in light Breeze.

Commit dab7fdd with current Breeze/Breeze Dark color schemes:

In T10997#207688, @mglb wrote:

In T10997#207569, @ngraham wrote:

I have to be honest here though: I'm having second thoughts about losing the blue background for the checked checkboxes and radio buttons. I think it makes them fade into the background more (especially with Breeze Dark)

Why should they stand out more than other controls?

There are two groups of new users:

• Those who install the system and use it later:
  • All this stuff should be available when the system installs itself. Users have to wait until it completes anyway, so this is probably the best moment.
  • If they had something better to do during installation, they are self-confident enough to find "New user guide", "Help" or something in application launcher.
• Those who get already installed system:
  • Important option to have: language/region selector. I think many devices with Linux/KDE come from smaller companies, which don't have large official distributors in each region, so the system uses US English by default. The first thing we should do for people who don't know English is to talk to them in their language (and don't confuse them with inverted date format :) ).
  • You probably want to give them possibility to change their name/login, password.

In T10997#207569, @ngraham wrote:

I have to be honest here though: I'm having second thoughts about losing the blue background for the checked checkboxes and radio buttons. I think it makes them fade into the background more (especially with Breeze Dark)

Going back to this. From visible things: implemented drawing of checkboxes/radios in menus; selected list items have checkboxes with hover&focus style.

There's also floating search bar in Konsole:

In D25123#558363, @ndavis wrote:

switching to that system means we would need to change many icons.

In D25123#558205, @ndavis wrote:

I tried seeing how it would look extended down to the bottom margin:

Yakuake icon moved to: https://phabricator.kde.org/D25123

I'll do the split today or tomorrow.

Inserting and applying styles can be done with icon template file with predefined swatches. Swatches (which are internally one-stop gradients) would be converted into style later with a script. Not trivial (i.e. not one line sed) to write due to indirect gradient use in inkscape, but also not really hard. Xml parser is the way to go. For extra newbie-friendly solution, "save as monochrome breeze svg" extension could be made.
From designer point of view use is really simple - in fill and stroke dock click "swatch" type and pick named color from a list.

This looks really nice and would indeed make this patch useful in the case of scrolling. But fading based on a timer would kill the main feature I see in this: having a visual reference to be able to see what has moved. Maybe we have to find something in between the original proposal and this. What do you think ?

Why do you replace action icons instead of adding separate colorful icons for use in preference dialogs? Right now all action icons are "monochrome", making few of them colorful will introduce inconsistency.

There is no merge commit when it is not necessary, and commits are not usually squashed (at least in Konsole, quick look at Okular says the same), so a MR author should put the keywords in one of the commits. You can check commits on a branch (or in commits tab in merge request) and ask commiter to fix commit descriptions. However, force-push is not allowed in some cases, so that might be impossible (IIRC).

Gitlab's Merge Request description is not placed in a commit (at least when there is no merge commit, which is default). Each commit in merge request has its own independent description.
Please see "02 Oct, 2019 (5 commits)" in https://invent.kde.org/kde/okular/commits/master - this is the result of mentioned merge. Hooks didn't catch bug entries because they are not in commits.

Please note that Konsole icon is intended to be personalized icon/"logo" (see T10243).
The prompt symbol is thick as it is main symbol (like symbols in e.g Plasma, Akregator, Kile, "K" icons/logos) - the window-like background (or just square in var C) is just secondary addition.

Brighten background

Right one (larger shadow size). Plasma popups open above windows, yet they cast a lot smaller shadow than window shadow right now.

Yes, I'll create review soon

In T10243#202901, @alex-l wrote:

As I said in another comment an example of problem in Inkscape is ">" symbol in Konsole 48x48px icon.

In T10997#203338, @ndavis wrote:

In T10997#203309, @mglb wrote:

In T10997#203145, @ndavis wrote:

they have a visible area of 20px vs 16px for the older version.

Yes. Labels have similar height (with default font size), so UIs won't grow much (if at all) and distances between checkboxes/radios are now similar to distances between other controls.

They do? Is this including the margins?

In T10997#203145, @ndavis wrote:

I noticed that the new checkboxes/radio buttons don't apply to menus

In T11714#203219, @vladimirmikulic wrote:

@mglb You didn't read my previous reply. As I said this is not the final version, the text is a placeholder, don't you all see lorem ipsum???

In T11714#203207, @ognarb wrote:

In T11714#203147, @KonqiDragon wrote:

In T11714#202597, @ognarb wrote:

@mglb

It's beautiful, but not perfect.
As a guest, i see "Read more" buttons near different products, but i'm not interested to read it because it's hard to understand what it is.
Also i think it's kool to giving a different backgrounds to each selections, as @mglb said.

I think it makes only sense to have different backgrounds color, if there is a meaning behind it. For plasma desktop they were some distinct section with each a different wallpaper. In this case, I see less a need for it.

I need some more time (~week) for fixes and cleanup.