Update ellipse shadow comment again and rounded rect shadow parameter name

Actually, it might not even an optical illusion. It might just be because my laptop screen is low quality :(
Sorry for all the fuss

Edit ellipse shadow comment

It may just be an optical illusion. Sometimes red next to blue or another highly saturated color will appear to be 1px higher than it actually is.
Here's a white icon:

I think the larger close icon looks nicer and more in line with window decorations:

In D25334#578285, @niccolove wrote:

Breeze dark highlight is currently #3daee9 in the Breeze Dark colorscheme. If that's too light, we could darken it there, right?
Currently it's:

Darker could be (example value):

Otherwise, the highlight effect could be made more transparent so that it's darker, but that would be a problem for consistency, as the same highlight color is also used throughout the desktop theme.

Visually LGTM

In D25539#579057, @ngraham wrote:

IIRC macOS's equivalent to this KCM uses instant apply (everything in macOS is instant apply) and they have a modal dialog with a revert timer in it. But I believe it's only shown when you change the screen; it isn't shown for anything else.

In T12372#214029, @mgallien wrote:

I used to regularly test with Breeze dark color scheme but somehow forgot to do it for the current stable version. Please, if you can test and open bug reports, that would be really nice.

In D25539#578688, @romangg wrote:

In D25539#578624, @liushuyu wrote:

Any other suggestions for this patch?

From a UX perspective the general question is if a revert timer makes sense when we have already the "Apply" action. As previously said I think it makes sense if we had instant-apply. I am currently going into this direction with D26038 but it does not yet do instant-apply. So my current leaning would be to wait until we have that and then revisit the revert timer.

Could you look in a separate patch into how instant-apply would work with the current KScreen KCM (or on top of D26038)? That would be great.

In T12192#214002, @zachus wrote:

I stick with the old trusty kmenu, come hell or highwater.

+1

In T12372#213921, @ngraham wrote:

+1

Makes sense to me.

Whoops, didn't mean to give my official approval

+1 visually

In D19890#577833, @hpereiradacosta wrote:

As a side remark: did you check how it looks when one selects "text under icon" or "text beside icon" for toolbar button ?

fix code style

Remove opacity change

In D26001#577830, @hpereiradacosta wrote:

I would avoid changing the alpha of the color though because: it makes no difference, and it is unrelated to the issue. Should be a different commit (which you can do without review if you really think it is important)

@broulik Does this fix the problem for you?

I don't find this better than the current form:

In D25925#576514, @ngraham wrote:

Or maybe what we need is a new "audio playing" embem/icon that's designed to be used to badge icons and comes with its own background. Of course that woludn't be FDO compatible with other icon themes, unless we named it something like audio-volume-high-emblem, which puts the emblem bit in the wrong place, and it would look bad with other themes.

In D19890#577221, @hpereiradacosta wrote:

Confused about 2: I thought icon size was the same for flat and non flat toolbuttons (see oxygen-demo5, buttons tab)

We could also do these things:

• In Dolphin, mimic the back/forward buttons in Firefox/Chromium/Falkon by making the right click menu provide the history instead of the normal menu for manipulating the toolbar. Inconsistent with what we normally do, but not unexpected for anyone used to web browsers. Clicking and holding is also awkward and slow for mouse and touchpad users.
• Remove the feature. It's not essential, but it is nice to have.

Ok, so there is an overlap problem, but it's quite rare. It happens when an icon uses 100% of the available space in the bottom right corner (or left with RTL, I think).
Here I changed the stop icon in KDevelop to the icon for Codelite:

+1 for readability

In D19890#577135, @ngraham wrote:

I'm not sure how to do that in the Breeze style here; can you show me?

One problem I see with this is that the tops of the down arrows are a bit blurry. The way to fix that is to increase the size just enough that they fill the pixel. The bottom point should also have a MiterJoin so that it isn't a horizontal flat tip on high DPI screens.

• increase line thickness for 48 and 64 px

In D25897#576015, @ngraham wrote:

The straight lines in the system tray items from my screenshot are definitely 1px strokes. But all the curved lines look thicker by virtue of not being able to align to the pixel grid. And most monochrome widgets have thicker lines when added to a tall panel:

This may be a side effect of scaling up smaller icons, but I think the thicker strokes work well for a large panel.

In D25897#575934, @ngraham wrote:

Thanks. However I wonder if the stroke width ought to increase for the larger sizes? Having such skinny lines looks a tad odd to me IMO:

I think visually, I prefer the sidebar on the left.

In T12192#213467, @ngraham wrote:

The common case is the user clicking on the panel item to launch it, which means that the cursor will be in the bottom-left corner. This makes me realize that we've reversed the position of the category list and might want to consider moving it back to the right side where it currently is, or else there's the risk of accidentally changing the category when moving the cursor up and to the right to click on one of the entries in the view.

In T12192#213434, @romangg wrote:

What's important is minimizing mouse travel time for common actions and maximizing it for rare ones. Where is the cursor normally? Will it be over the launcher button or somewhere in the middle of the screen? From that I would decide if the search field belongs to the top or not. The system buttons should be on the other side of where the mouse cursor normally is to maximize travel time for these rare interactions.

Another question is if KRunner functionality should be integrated and if yes how to depict it. If the search field is on the top we could show program icons below and additional results like 2+2 above. Or all of it in list form in the main area.

I agree, I hate this kind of ambiguous language.

In D25820#574397, @vinzenzv wrote:

In D25820#574119, @ndavis wrote:

Good start! The lens flare looks upside down

That was intentionally to make it distinguishable from digiKam.

I agree with this.

I don't agree that it's ugly. We normally use LineEdits for search boxes, so people will recognize it faster like that. The username/avatar can't be interacted with, so making them look similar sends the wrong message.

In D25814#574395, @filipf wrote:

Already asked in VDG, but repeating here: how would we handle dark separators on really dark color schemes?

This is the most downloaded color scheme and it won't work well with dark separators: https://store.kde.org/p/1294011/

wait scratch that, it does work. I had to remove the 22-22- prefix, which is what you normally need when you have multiple icon sizes.

In D25815#574394, @vinzenzv wrote:

In D25815#574216, @ndavis wrote:

Here's one way to make a nice looking trapezoid in the Breeze style. I started by making a stroke with end points in the middle of pixels and the other settings I mentioned in my first comment. Then I converted it to a path and I added a 2px high rectangle to increase the thickness of the bottom part.

So as you already built it the icon is finished, right?

In D25814#574356, @hpereiradacosta wrote:

I meant: do the "light" (with window text color) toolbar icons play well with dark toolbar separators as opposed to current semi-light toolbar separators

Buttons should probably be this large:

yeah, gotta have room for the labels

In T12192#213281, @manueljlin wrote:

In T12192#213279, @ndavis wrote:

Why not make the grid 4 spaces wide? Then make the list view match that and you'll have a fairly reasonable amount of space for both views.

Hmm, while it does the job, I don't know abut sacrificing 4 icons

In D25814#574250, @hpereiradacosta wrote:

• You should add toolbar separators, tabboxes and group boxes to that. For toolbar separators, I wonder how this would play with monochrome (color-themed) icons.

One more thing, should the file view be a list view or a tree view? I personally find tree views for file browsing almost universally superior, but I'm not certain that it's appropriate. Simple Menu isn't meant to replace dolphin, but it could be a fast launching point.

In T12192#213278, @manueljlin wrote:

Seems like the best way to do it, yeah. I will add a Recents category for files and change the image from the task. I only have one question, should the size change when the tabs are switched?

or not

which would be easier to implement but, look at that unused space, oof.

@hein brings this up in the VDG chat every now and then when we start talking about colorscheme colors: https://www.eikehein.com/colors.pdf

@ngraham +1, sounds reasonable

Here's one way to make a nice looking trapezoid in the Breeze style. I started by making a stroke with end points in the middle of pixels and the other settings I mentioned in my first comment. Then I converted it to a path and I added a 2px high rectangle to increase the thickness of the bottom part.

In D25815#574150, @broulik wrote:

I chceked transmission git code and the icon name it uses is actually transmission-tray-icon, so you want to have a transmission.svg file and the "id" to be transmission-tray-icon, then it should work: https://github.com/transmission/transmission/blob/master/qt/MainWindow.cc#L302

In D25814#574129, @hpereiradacosta wrote:

Few more comments on this:

• general: you will never be able to make all the opiniated people happy, and you have to draw a line (otherwise your code will become bloated, buggy, and unmaintainable)
• regarding this specific case: many widget style will not implement this new color. For those this will just generate bugs reports: why is my color scheme not respectd ?
• some widget styles (oxygen at least, but I'm sure there are others) use two colors for frames and separators, to mimic shadows or relief effects. Adding one single color for this will not fit such schemes.
• in the end if you need an extra color for a given theme (be it future-breeze or whatever), there is also the possibility to add it as a extra option for this specific theme, rather than forcing it to kcolorscheme and imposing it to all styles (or making kcolorscheme broken for all the styles that wont use it). This is how window decoration shadows and glow were handled to oxygen. I think this change will break more things than it will fix, especially if the fix is to make some opinionated people happy.

In D25814#574160, @davidedmundson wrote:

Can we clarify what separators we're referring to.

Good start! The lens flare looks upside down and the icon needs more pixel alignment. I feel like the red/green/blue colors of the center area are a bit too dark as well.

@hpereiradacosta, Fair points and I'm glad you spoke up. JFYI, I'm in no rush to land this and I will consider reserving this change for KF6 if experienced KDE devs think that is best.

In D25815#574111, @vinzenzv wrote:

In D25815#574103, @ndavis wrote:

The actual name of the icon is transmission, so you would have to rename the file to that and add id="transmission" to the group. Since this is a desktop theme icon, you would also have to add an invisible 22x22 rectangle to the group.

However, even after doing all that myself, I can't get this icon to work. I'm not sure why. It doesn't work with transmission-qt either.

I rebuilt the whole icon taking the SVG of Konversation. Maybe I messed up something with the initial one.

The actual name of the icon is transmission, so you would have to rename the file to that and add id="transmission" to the group. Since this is a desktop theme icon, you would also have to add an invisible 22x22 rectangle to the group.

Hey, thanks for the patch!

• update @since version

In T10413#213139, @ngraham wrote:

In T10413#213130, @ndavis wrote:

Update with a conversation I had on #kde-devel: https://webchat.kde.org/#/room/#kde-devel:kde.org/$157537933341042bwtvA:kde.org

Another idea from that conversation was to append -symbolic to icon names requested by applications for buttons/menus and then make all monochrome icons use the symbolic suffix.

This seems like it could succeed, but would require a lot of porting work in applications. Then again that work could be phased in over time because the icon name changes would be forwards-compatible. And they could make be scripted too. Sounds like this could be a way to break the logjam!

• change minimized bg opacity to 8%

Update with a conversation I had on #kde-devel: https://webchat.kde.org/#/room/#kde-devel:kde.org/$157537933341042bwtvA:kde.org

In T10611#213118, @GB_2 wrote:

We could also set the "Prefer dark theme" preference depending on your color scheme (like the filter combobox added in D18646).