Using View Background is semantically incorrect. If you want to change the color, you should patch the color scheme.

In D27122#605804, @ndavis wrote:

Using View Background is semantically incorrect. If you want to change the color, you should patch the color scheme.

But in order to change ColorScheme-Background I should change Window Background in the colorscheme, which would make all KDE apps lighter, right? I don't think that it makes sense to use the same color of windows for dialogs, since they're not windows, especially since they are also transparent and that requires adjusting the color.

In D27122#605969, @niccolove wrote:

In D27122#605804, @ndavis wrote:

Using View Background is semantically incorrect. If you want to change the color, you should patch the color scheme.

But in order to change ColorScheme-Background I should change Window Background in the colorscheme, which would make all KDE apps lighter, right? I don't think that it makes sense to use the same color of windows for dialogs, since they're not windows, especially since they are also transparent and that requires adjusting the color.

If you need to adjust the color specifically for the desktop theme, you should adjust the color schemes of the Plasma Light/Dark desktop themes.

In D27122#605973, @ndavis wrote:

In D27122#605969, @niccolove wrote:

In D27122#605804, @ndavis wrote:

Using View Background is semantically incorrect. If you want to change the color, you should patch the color scheme.

But in order to change ColorScheme-Background I should change Window Background in the colorscheme, which would make all KDE apps lighter, right? I don't think that it makes sense to use the same color of windows for dialogs, since they're not windows, especially since they are also transparent and that requires adjusting the color.

If you need to adjust the color specifically for the desktop theme, you should adjust the color schemes of the Plasma Light/Dark desktop themes.

Gotcha.

Also, you can set contrast effects per desktop theme. If you do that, you may be able to improve the look of breeze light without hurting breeze dark. Let the Breeze desktop theme be a fairly neutral one that works well with most colorschemes.

In D27122#605975, @ndavis wrote:

Also, you can set contrast effects per desktop theme. If you do that, you may be able to improve the look of breeze light without hurting breeze dark. Let the Breeze desktop theme be a fairly neutral one that works well with most colorschemes.

Yes, I was just doing that as well. One question: if I change the colorscheme for background of default Breeze, it will become the same as Breeze Light, won't it? Should I remove that one? It would be probably better than having two different ones but the default one (Breeze) is a bit more gray-ish than the other (Breeze Light)

In D27122#605976, @niccolove wrote:

In D27122#605975, @ndavis wrote:

Also, you can set contrast effects per desktop theme. If you do that, you may be able to improve the look of breeze light without hurting breeze dark. Let the Breeze desktop theme be a fairly neutral one that works well with most colorschemes.

Yes, I was just doing that as well. One question: if I change the colorscheme for background of default Breeze, it will become the same as Breeze Light, won't it? Should I remove that one? It would be probably better than having two different ones but the default one (Breeze) is a bit more gray-ish than the other (Breeze Light)

Keep in mind there's the Breeze Light desktop theme (uses the Breeze color scheme) and the Breeze Light color scheme (not that great). What are you referring to?

In D27122#605981, @ndavis wrote:

In D27122#605976, @niccolove wrote:

In D27122#605975, @ndavis wrote:

Also, you can set contrast effects per desktop theme. If you do that, you may be able to improve the look of breeze light without hurting breeze dark. Let the Breeze desktop theme be a fairly neutral one that works well with most colorschemes.

Yes, I was just doing that as well. One question: if I change the colorscheme for background of default Breeze, it will become the same as Breeze Light, won't it? Should I remove that one? It would be probably better than having two different ones but the default one (Breeze) is a bit more gray-ish than the other (Breeze Light)

Keep in mind there's the Breeze Light desktop theme (uses the Breeze color scheme) and the Breeze Light color scheme (not that great). What are you referring to?

I'm referring the the Breeze Light desktop theme, which I guess uses the "color" file to look, well, lighter, but it won't be different if I make the color file for Breeze as well

In D27122#605982, @niccolove wrote:

In D27122#605981, @ndavis wrote:

In D27122#605976, @niccolove wrote:

In D27122#605975, @ndavis wrote:

Also, you can set contrast effects per desktop theme. If you do that, you may be able to improve the look of breeze light without hurting breeze dark. Let the Breeze desktop theme be a fairly neutral one that works well with most colorschemes.

Yes, I was just doing that as well. One question: if I change the colorscheme for background of default Breeze, it will become the same as Breeze Light, won't it? Should I remove that one? It would be probably better than having two different ones but the default one (Breeze) is a bit more gray-ish than the other (Breeze Light)

Keep in mind there's the Breeze Light desktop theme (uses the Breeze color scheme) and the Breeze Light color scheme (not that great). What are you referring to?

I'm referring the the Breeze Light desktop theme, which I guess uses the "color" file to look, well, lighter, but it won't be different if I make the color file for Breeze as well

Don't make a color file for the breeze desktop theme. It doesn't have one so that it can use any system color scheme.

In D27122#605987, @ndavis wrote:

Don't make a color file for the breeze desktop theme. It doesn't have one so that it can use any system color scheme.

Uhm; but then, there's no way for the default theme to not look gray-ish without changing the globar colorscheme? (Also - since this is approaching a discussion that would work better in chat, can we talk in the VDG chat directly?)

I've done the dark theme again, should be nice now

Light version still looks good to me. For the dark version, I still see a difference between the background opacity of the panel and the pop-up:

Still not installing the file for me. Is this working for you?

I'm unable to build anything right now unluckly so I tried to use code from the breeze folder but I'm not good at cmake. I will try to make cmake for me tomorrow

Nope, I'm absolutely unable to build plasma-framework right now, I have many problems that I don't understand :-/ Also, I have 0 Cmake experience
If somebody has time, can they look into how to make Cmake read that file?

In D27122#607167, @ngraham wrote:

Please add a comment in the Description section of this patch explaining why the previously disabled Intensity value is now enabled.

✓

Do you still see Breeze after installing this? For some reason, mine disappeared, there's just Breeze Light and Dark
edit: seems like it was installed as "veggy" instead of "breeze", weird, but maybe that's just on my machine, I don't see any change that could lead to that

I personally choose 0.4 for opacity, but I was now thinking whether higher or lower values could be better. I took 50 screenshots in different conditions, but since those are a bit difficult to upload to Phab, I also made a website which helps you pick a value: https://niccolo.venerandi.com/backstage/files/opacity/compare.html - I'd suggest using fullscreen and trying a couple of times. It's very hacky and bad-written, but it's only supposed to be a quick tool.
You can also see *all* screenshots at https://niccolo.venerandi.com/backstage/files/opacity/{0.2,0.4,0.5,0.6,0.8}/{1:10}.png

Edit: some results that I collected so far: [0.53, 0.51, 0.33, 0.31, 0.6, 0.2, 0.73, 0.77, 0.7, 0.57] - Right now in this patch it is set to 0.4, so maybe I would make it a bit higher, like 0.55/0.6

My result was 0.644.

But ultimately, don't let this become design-by-committee. This is your patch, and your proposal. It's good to take into account feedback, but not to the extent that it compromises what you're trying to accomplish in the interests of pleasing people who fundamentally don't like it and never will. You do need to maintain text legibility, but beyond that, the people who just don't like transparency won't be happiest with any opacity value less than 1. If you try to placate them, you'll be pushed in the direction of compromising your design vision. If your design vision is fundamentally sound, those people will just need to adapt a bit.

(and I say this one of those people :) )

In D27122#608074, @ngraham wrote:

But ultimately, don't let this become design-by-committee. This is your patch, and your proposal. It's good to take into account feedback, but not to the extent that it compromises what you're trying to accomplish in the interests of pleasing people who fundamentally don't like it and never will. You do need to maintain text legibility, but beyond that, the people who just don't like transparency won't be happiest with any opacity value less than 1. If you try to placate them, you'll be pushed in the direction of compromising your design vision. If your design vision is fundamentally sound, those people will just need to adapt a bit.

(and I say this one of those people :) )

Thanks for the feedback!
My personal opinion is that something like .6 looks best, and I think the general feedback I got is in line with that. I will update the values accordingly :-)

In D27122#608324, @ndavis wrote:

Still uses ViewBackground on panels. For panel popups, you wanted to use a header area like the systray mockups, right? If so, the dialog SVG could use ViewBackground and you should mark this patch as dependent on the toparea patch.

Using Background for panels would break the visual integration with dialogs, so I would avoid doing that.

Regarding panel popups / dialogs; I'm already working on the toparea patch - https://phabricator.kde.org/D27189 - but I was thinking, the problem with using Background is the controls on top of it e.g. kickoff search. Since the transparency makes the background color not as gray, the only problem is when things are opaque (I remember we talked about this in the VDG chat). Now, *there is* a version of Breeze opaque in the breeze/opaque/ directory which is used when compositing is disabled. For that one, I did leave ColorScheme-Background, so the problem is not there when the actual opaque version is used. I think that people who want things to be 100% opaque will install a theme rather than manually editing the svg, so they would not have that problem as well. That isn't to say that I won't work on the top area, just that I would not make the this patch dependent on it.

I also tried to tweak the intensity value to make the normal ColorScheme-Background fine, but I did not have any success. It seems like it's not a color which manages to work in this usecase, while ColorScheme-ViewBackground is okay.

Arcpatched and compiled and I was getting an overly transparent Breeze Dark:

It was only when I turned Contrast Effect off and then on again that I was seeing what's in the test plan.

We should still investigate this because I also reproduced it in a different install.

In D27122#608443, @niccolove wrote:

Using Background for panels would break the visual integration with dialogs, so I would avoid doing that.

Regarding panel popups / dialogs; I'm already working on the toparea patch - https://phabricator.kde.org/D27189 - but I was thinking, the problem with using Background is the controls on top of it e.g. kickoff search. Since the transparency makes the background color not as gray, the only problem is when things are opaque (I remember we talked about this in the VDG chat). Now, *there is* a version of Breeze opaque in the breeze/opaque/ directory which is used when compositing is disabled. For that one, I did leave ColorScheme-Background, so the problem is not there when the actual opaque version is used. I think that people who want things to be 100% opaque will install a theme rather than manually editing the svg, so they would not have that problem as well. That isn't to say that I won't work on the top area, just that I would not make the this patch dependent on it.

I also tried to tweak the intensity value to make the normal ColorScheme-Background fine, but I did not have any success. It seems like it's not a color which manages to work in this usecase, while ColorScheme-ViewBackground is okay.

This is really about how this fits with our color scheme system, not so much about the aesthetics of transparency and blur. If you need different colors from normal to get this to look right, how will it look when you use other different colors? How does this look with color schemes besides Breeze and Breeze Dark (e.g., Arc Dark, Materia Dark)? If it only works properly with Breeze/Breeze Dark because ViewBackground is a lighter/darker color, this isn't going to work for all color schemes. You'll end up having to use a custom colors file anyway (as in Breeze Light/Dark desktop themes) to guarantee that everything will look right.

Now that I've had the chance to try this patch, I can some issues. Even if you use a custom colors file, it seems this patch only looks right when there are no windows open, which doesn't seem realistic.

Arc Dark:

Materia Dark:

Nordic-Darker:

Even Breeze Dark has trouble:

That's not to say the current situation is perfect, but the color difference isn't so stark (Breeze Dark):

Light themes don't really have this problem, but dark themes have a big problem.

Right, I also noticed the color-aware theme now has somewhat more pronounced discrepancy between the panel and the popups when dark color schemes are used.

One thing I notice other platforms do is to make the panel more opaque when there's a maximized window up against it. That resolves the issue of a translucent panel reflecting the wallpaper color in a way that's jarringly different from pop-ups that appear on top of window content.

• Breeze panel and dialog being different when using a dark theme
• Avoiding controls to be used in ViewBackground areas / using Background Breeze color without it looking gray

I have no idea how these could be fixed without just using a color file-d theme by default :-(
The top area could work for the second one, but stuff like wifi password box and clipboard box might probably still fall outside...

• Breeze panel and dialog being different when there's a maximized window

I have no idea how this could be addressed at all. It's not currently doing that either. And making the panel opaque on maximized app would not work either unless the dialog is also fully opaque. Which I'm not a fan of, in this patch.

tl;dr: kinda stuck with this one, not sure what I could do to address those problems. I should keep thinking about this.

Maybe the look could be implemented first for just Breeze Light and Dark and not Breeze first, but it would probably be very weird to explain it to the user ("Breeze is more opaque and follows the colorscheme, Breeze Light is the opposite").

I think rather than adjusting hardcoded opacity in the SVGs, we need to make configurable plasmashell opacity a reality. Then, if we want to do an effect like what Nate described, we could have a way to automatically adjust the global plasmashell opacity.

In D27122#609276, @ndavis wrote:

I think rather than adjusting hardcoded opacity in the SVGs, we need to make configurable plasmashell opacity a reality. Then, if we want to do an effect like what Nate described, we could have a way to automatically adjust the global plasmashell opacity.

I agree, but I think this kind of fall outside the scope of this patch (change the default plasma look), also because even with the slider, the above problems would persist. Rather, I was discussing that in the last post of https://phabricator.kde.org/T11925

@niccolove wrote:
Breeze panel and dialog being different when using a dark theme

I'm working on fixing the blur effect thanks to Alex Nemeth help.

Regarding maximized windows: I don't think it's possible to make the dialog and panel feel united in this case; windows has this problem as well:

Couple of screenshots more from this patch:

I felt that the transparency was not working very well with the headerbar on some wallpapers, so I toned down the transparency a bit, going from

Hmm, I think you need to rebase to remove unrelated files in this patch e.g. dropjob.cpp ... ?

In D27122#617614, @trmdi wrote:

Hmm, I think you need to rebase to remove unrelated files in this patch e.g. dropjob.cpp ... ?

Definitively. *sigh*

In D27122#617594, @niccolove wrote:

Now that is relaxing :) I like it.

I'll make this patch again, as much has change since then, there are things I'd do differently, and I'm not a fan of rebasing svg files. I will post the progress I did there.