In D22359#536055, @ngraham wrote:

Is there any way we can preserve the original goal of using a monochrome icon here for small sizes?

In D22359#536066, @ngraham wrote:

Those are in the System Tray, which always shows monochrome icons. Show Desktop is a standalone widget, which has logic to switch its icon between monochrome and colorful icons depending on the size of the container that the icon is inside.

In D22359#536064, @KonqiDragon wrote:

In D22359#536063, @ngraham wrote:

In D22359#536057, @ndavis wrote:

In D22359#536055, @ngraham wrote:

Is there any way we can preserve the original goal of using a monochrome icon here for small sizes?

Yes, it is already done. Lower the panel icon size to 16 or 22 px.

That doesn't help the huge fraction of people who never touch the default settings though. What's especially silly IMO is that the default panel height is 36px, at which size everything with a colorful icon version gets the colorful version... but if you reduce the panel height just one tick to 34px, the icons get smaller and everything becomes monochrome and it all looks great.

I feel like we should either slightly reduce the default height of the panel to 34px, or change its icon sizing logic so that the threshold for everything turning colorful happens at some size that's greater than 36px.

Why the Notifications, Volume, Network, etc. icons are monochrome, but "Show desktop" and "Minimize all" icons is hard to make a monochrome?
Colored icon of "Show desktop" and "Minimize all" is bigger that other monochrome icons.

In D22359#536058, @KonqiDragon wrote:

I really don't like that in the Plasma 5.17 Beta you returned a colored icon, when in Plasma 5.16 you added a monochrome icon i was glad. I don't like this regression. We need to talk with Goal: Consistency and VDG about how to return and make a monochrome icon better.

In D22359#536055, @ngraham wrote:

Is there any way we can preserve the original goal of using a monochrome icon here for small sizes?

In D24127#535826, @cblack wrote:

In D24127#535555, @ndavis wrote:

@cblack Can you change the focus state to only have a blue outline? This behavior is really confusing, even though it seems consistent with Breeze: -snip-

I'd rather not diverge from the Breeze here for a few reasons:

• I don't have a guarantee that Breeze is going to have the exact same change
• Breeze GTK is supposed to look like the current state of Breeze, with adaptations where necessary due to differences between GTK and Qt
  
  If Breeze gets the change, I'll add it.

In D24127#535558, @ngraham wrote:

In D24127#535555, @ndavis wrote:

This behavior is really confusing, even though it seems consistent with Breeze

I really dislike this about Breeze itself and would welcome a fix there too. Then maybe we can make the default button actually be blue, rather than an almost-indistinguishable shade of gray (See https://bugs.kde.org/show_bug.cgi?id=386158).

In the beginning of the video where it looks like I'm just hovering, I'm actually clicking once every half second.

@cblack Can you change the focus state to only have a blue outline? This behavior is really confusing, even though it seems consistent with Breeze:

Ah, I only tested Breeze Dark, which uses the same white text color for everything.

icons/apps/22/elisa.svg does not apply cleanly. Not sure why.

Sliders look fixed, but the scrollbar still isn't right. The scrollbar should have the same groove color as the sliders.

Nothing changed

Looks fixed on my end

I think the alpha levels need to be swapped.

The slider backgrounds are too bright on Breeze Dark

Actually, not sure if this code works how I think it works. 0.2 should actually be less dark than 0.3 if I understand it correctly.

What is that white dot in the corner?

Could you separate these into different patches? It's generally not good practice to land a bunch of unrelated changes in one commit.

Works just as well as it did before the patch for me.

In D24091#534786, @ngraham wrote:

Do you think I should always have a separator above the Full Screen menu item? This should generally work fine, but it means that in case the MergeLocal content is empty, there will be two separators in a row. I don't know how likely this is to ever happen, but it could. Thoughts?

I'm not sure what MergeLocal does or when it would be empty.

I think it's redundant to say "charge level" since the percentage is always the charge level. I also think keeping the language consistent is a good idea. The volume tooltip says "Volume at %", which is why I originally suggested "Battery at %".

In D24070#534719, @mthw wrote:

@ndavis So, generally, you would like to switch the two lines?

In D24070#534585, @ngraham wrote:

In D24070#534447, @ndavis wrote:

In D24070#534378, @broulik wrote:

Volume shows the percentage in the main title so this is inconsistent now.
Perhaps instead show some other information like remaining time in the subtext?

Yes, perhaps it should be like this:

Battery at 100%
Plugged in, not charging

Yeah, that makes sense to me. Put the primary information in the first line, and additional information in the second line. For example:

4:58 remaining
55% Battery charge level

2:08 until fully charged
78% Battery charge level

2:08 until fully charged
78% Battery charge level

Battery 100% charged
Plugged in

(not totally sure about that last one, just an idea)

In T10243#201445, @alex-l wrote:

Most common problems for me are: (1) path that is correctly displayed but can't be edited with Inkscape, just moved around

In D24070#534378, @broulik wrote:

Volume shows the percentage in the main title so this is inconsistent now.
Perhaps instead show some other information like remaining time in the subtext?

In T10243#201333, @ngraham wrote:

In T10243#201329, @alex-l wrote:

EDIT: I have already said this here and there but please don't run any automated script to SVG icons, because when opening them back in Inkscape they are corrupted and everytime I edit a Breeze icon I have to do additional work to fix shapes and gradients corrupted by the scripts.

This is something you should bring up in the VDG chatroom and discuss with @ndavis in particular as we currently make heavy use of these scripts for optimization purposes. Hopefully we can come up with a solution together.

It would be nice to have this for 5.17. Then I can add Cuttlefish to my workflow wiki.

+1, but I'm curious what others have to say. I definitely agree that Meta should be for global shortcuts and global desktop shell related shortcuts in particular.

Remove extra declaration of first

The orientation toolbuttons seem oversized.

In D24008#532936, @ngraham wrote:

Doesn't this mean that the visual appearance of the dial will change depending on what the maximum value is?

Is this screenshot outdated? Why does the selected item extend outside the width of the list?

There seems to be a blank entry at the bottom of the category list:

The clickable area is significantly smaller than the highlight.

Text still gets cut off on the left side:

The sidebar seems a bit wide. Maybe remove the 128px view? As a Breeze icon designer, I don't really need it.

The colorscheme selector does not work

In D23942#531337, @GB_2 wrote:

In D23942#531330, @ngraham wrote:

Shouldn't the checkmark be green?

FWIW, both should be black/white. Disabling is not a destructive action like removing.

In D23942#531279, @guoyunhe wrote:

@ndavis, @broulik, @ngraham, I made some change. Can you have another look?

Oof, all of the font icons that contain an 'A' need to be cleaned up someday. The 'A's aren't even 16px tall in the 22px icons and the line thickness and alignment is all over the place. I guess that's something for another patch. For now, we should maintain consistency with the existing font icons.

There's a bit too much space around the checkmark.

Flexibility sounds good, but how am I supposed to know what I'm looking at or what options to pick? Perhaps it's better to handle the backends automatically, if possible?

I find the use of filled and empty stars visually odd. They're like Jerry-rigged radio buttons that look like PushButtons. We also can't guarantee that star-shape will be empty and favorite will be filled in 3rd party icon themes. It's not at all obvious from the names of the icons that one should be filled and one should be empty either.

In R98:523249683744d533570fd12730ee2b0be6c5ed90#3819719, @freeno wrote:

I have some buttons that are half white and full white sometimes when they should not be. This is the latest version.

We should probably redo or completely remove the current Qt icons since they're very Qt4 and look outdated. Unless our Qt icons are updated, I don't think we should have this symlink.

In D23876#529485, @ngraham wrote:

Better, but now the padding is inconsistent between the sides and bottom:

Look at the top of the view in both screenshots and bottom of the view in the 2nd. Rather than cutting off the content of the items right at the separator as they go out of the visible area, they get cut off early. I think the way they were cut off before was better. I'm guessing that the area around the separator was extended.

The spheres around the planet need better pixel alignment, particularly on the 16, 22 and 32px versions. This will require remaking parts of the logo so that it fills pixels. Round to the nearest size in whole pixels. Half pixels can be tolerated sometimes when the area is greater than 2x2, but pick what looks good to you at 100% zoom in general. The planet itself could have better pixel alignment too, but it's not as critical.

In T11093#199099, @onvitaik wrote:

Here's my 2 cents:

I think toolbars themselves are also inconsistent. Some icons will be followed by text, while some will not, and some icon-only buttons are also mixed with icon+text buttons. you can see, for example, here and here how that mixing happens.

Taking two other DEs as reference, their toolbars are usually only icons, icons with text, or just text, all with minimal mixing. The result is a uniform, consistent look, which makes them look really pleasing to the eyes. Examples: Gnome, MacOS.

In case of icon-only toolbars, tooltips on mouse over or a button press could give a description of the button's purpose. Having intuitive buttons for each action would be the ideal, though, as you'd be able to ditch the text, keep the toolbars compact, and free up space for more actions.

Fair enough.

Why not just keep New Tab/Window in the Context menu? The hamburger is already a bit overfull, even if we remove Redisplay. The context menu isn't that long by comparison and it wouldn't be any longer than it is with a folder selected.

In T11526#198734, @ngraham wrote:

I guess we can create colorful versions of action items on a need-to-have basis, as long as we commit to not using them for actual actions in buttons etc. for our own apps.

In D23757#528098, @ngraham wrote:

In D23757#528095, @ndavis wrote:

Why is it that sometimes Create New is in its own section and sometimes it's grouped with Open With or New Tab/Window?

As for Add to Places, perhaps it should just be in its own section above the services section? It doesn't really go with anything else and I was never bothered by it being in its own section.

One of the reasons why I wanted to do this patch is because I think single-item sections are ugly and make the menu feel cramped and overwhelming, and the goal was to get rid of them as much as possible.

Why is it that sometimes Create New is in its own section and sometimes it's grouped with Open With or New Tab/Window?

+1

What are "Values of an output"? I don't understand what these 2 settings do.

In T11526#198388, @ngraham wrote:

IMO we should not be using action icons in these larger sizes in the first place--at least not in apps. The places where we are doing this should be corrected in the apps themselves.

For example Okular's sidebar category chooser is something I'm actually working on removing and transforming into a more standard combobox-based category chooser UI.

In the Places panel we should be using places icons for entries so that they have pretty large sizes.

Plasma uses large >22px monochrome icons in a lot of places, so maybe we should concentrate on that. I think they can look acceptable at up to 32px size, maybe with bigger line weights. At larger sizes, it's probably not appropriate to use a monochrome icon, which suggests that if only a monochrome icon is available, it should be 32px in size as a maximum, and if more space is needed, we should maybe enclose it in a visible button with larger bounds rather than making it a toolbutton.

• A user may wish to duplicate the current view in a new tab or window
• A user may wish to create a file inside of a folder while at the level of a higher folder in tree/details view. In case that's hard to visualize:
  

It might make sense to put Add to Places next to Assign Tags. They're slightly related in that they're meant to make accessing some files or folders faster.