Created attachment 112086 [details] Old_Oxygen_Shadow_Style I like Breeze theme and window decoration. Can that feature be implemented in Breeze, like in old Oxygen? It's convinient with large number of windows.
Don't understand why it isn't in wishlist... And compare Breeze's shadow with Oxygen's.
Created attachment 112087 [details] Breeze's_shadow
That wouldn't make sense; the Oxygen effect was more of a highlight, but the Breeze effect is a shadow, not a highlight. What we could do is maybe reduce the shadow strength for inactive windows to help distinguish the foreground window from others. macOS does this.
(In reply to Nate Graham from comment #3) > What we could do is maybe reduce the shadow strength for inactive windows to > help distinguish the foreground window from others. macOS does this. Yeah, it's a good decision.
(In reply to Nate Graham from comment #3) > That wouldn't make sense; the Oxygen effect was more of a highlight, but the > Breeze effect is a shadow, not a highlight. > > What we could do is maybe reduce the shadow strength for inactive windows to > help distinguish the foreground window from others. macOS does this. macOS's shadows are also enormous, though, and reducing the shadow size for smaller shadows wouldn't make sense. E.g., I don't think reducing the shadow strength of inactive windows for medium-sized or smaller shadows makes sense.
Created attachment 120470 [details] A windows in Material Design at 1dp Maybe we can consider Material Design's shadow system? It's well defined and looks nicer to my opinion. More importantly, it fits the style of Breeze. So, many widgets may benefit from it. https://material.io/design/environment/light-shadows.html
I don't like that at all. It looks so hard on the bottom, and it's practically non-existent on the sides. We have our own design language, no need to copy Google. :)
Created attachment 123511 [details] Difference in shadow strength to differentiate inactive from active windows
I forked the Breeze window decoration and added a behaviour like you are discussing. It's not too difficult but adds a lot of clarity as to which window is selected.
(In reply to n4n0 from comment #9) > I forked the Breeze window decoration and added a behaviour like you are > discussing. It's not too difficult but adds a lot of clarity as to which > window is selected. Can you submit a patch to Breeze itself? That would be very much appreciated! I can help you through the process.
Sure, let me know what I have to do. Probably sign up on Phabricator, create a fork, send a pull request?
Just two cents on the different shadow strength. In principle no objection. However please note that (as in oxygen), the transition between active and inactive window is animated (you can see the animation in action if you increase the animation duration in the breeze config. from e.g. 15Omsec to 500). The shadow transition from strong to light between active and inactive should then be animated too, as is the glow in oxygen. Hopefully this will not be too resource consuming. If it turns out it is, I would be in favor of keeping the shadow size the same for the two states. Hugo
Created attachment 123533 [details] attachment-19238-0.html In my theme it is not animated as that is also not the case on macOS, which I'm trying to faithfully recreate. I could try to make it animated though. 28. Okt. 2019, 09:18 von bugzilla_noreply@kde.org: > https://bugs.kde.org/show_bug.cgi?id=393238 > > --- Comment #12 from Hugo Pereira Da Costa <hugo.pereira.da.costa@gmail.com> --- > Just two cents on the different shadow strength. > In principle no objection. > However please note that (as in oxygen), the transition between active and > inactive window is animated (you can see the animation in action if you > increase the animation duration in the breeze config. from e.g. 15Omsec to > 500). > The shadow transition from strong to light between active and inactive should > then be animated too, as is the glow in oxygen. > Hopefully this will not be too resource consuming. If it turns out it is, I > would be in favor of keeping the shadow size the same for the two states. > > Hugo > > -- > You are receiving this mail because: > You are on the CC list for the bug. >
Please do not animate the shadow. There is a transition animation in the decoration from active to inactive (which I personally odd and have it disabled), but that is much different from animating the shadow which would only make sense if the entire window were animated. When switching from one window to another, the entire window becomes visible immediately. Having a shadow fade-in would look very weird.
Created attachment 123534 [details] attachment-20697-0.html In full agreement with that. 28. Okt. 2019, 10:00 von bugzilla_noreply@kde.org: > https://bugs.kde.org/show_bug.cgi?id=393238 > > --- Comment #14 from Michael D <nortexoid@gmail.com> --- > Please do not animate the shadow. There is a transition animation in the > decoration from active to inactive (which I personally odd and have it > disabled), but that is much different from animating the shadow which would > only make sense if the entire window were animated. When switching from one > window to another, the entire window becomes visible immediately. Having a > shadow fade-in would look very weird. > > -- > You are receiving this mail because: > You are on the CC list for the bug. >
It is not so much a question of what one likes or not but of consistency. All transitions in breeze are animated, so this one should be too (for people who like smooth transition). Then, if you don't like them, you can disable them, just like you do now. Not having it upfront would be a consistency break (for breeze).
I disagree. The shadow and the title bar are separate components, and only the title bar is animated. As it currently stands, the shadow is NOT animated and should NOT be for reasons of consistency and otherwise.
Its not animated because it is not changed ...
The point is not whether they are same components with title bar or not. The point is that _all_ transitions are animated. Right now there is no transition. so no animatino. You add a transition you animate it.
I don't want to have a debate over what "consistency" demands and whether it's worth having. It's simply my opinion that animating the shadow would look awful and doesn't make sense (aside from conforming to one sense of "consistency" that one could easily argue is not desirable here).
Uh, anyhow; to implement this, all you have to do is inside the breezedecoration.cpp within void Decoration::createShadow(), add a few lines along the likes of this: > auto c = client().data(); > if ( !c->isActive() ) { strength /= 2 } This will take the previously defined const qreal strength and divide it by 2 if the window is inactive. You can also settle for other values. In my theme I made it a user setting to leave it at "Normal" (/=2), "Light" (/=4) or "None" in which case inactive windows will have no shadows at all. And depending on the outcome of your discussion, you can probably simply use a check for QPropertyAnimation::Running to animate a transition.
> auto c = client().data(); > if ( !c->isActive() ) { strength /= 2; } Missed a semicolon, sorry.
(In reply to n4n0 from comment #21) > Uh, anyhow; to implement this, all you have to do is inside the > breezedecoration.cpp within void Decoration::createShadow(), add a few lines > along the likes of this: > > > auto c = client().data(); > > if ( !c->isActive() ) { strength /= 2 } > > This will take the previously defined const qreal strength and divide it by > 2 if the window is inactive. You can also settle for other values. In my > theme I made it a user setting to leave it at "Normal" (/=2), "Light" (/=4) > or "None" in which case inactive windows will have no shadows at all. > > And depending on the outcome of your discussion, you can probably simply use > a check for QPropertyAnimation::Running to animate a transition. I tried doing this exact thing a few months ago but it didn't work, and when I asked some plasma developers for help, they couldn't understand why it didn't work. if you've managed to get it working, can you formally send a patch? Here is the documentation: https://community.kde.org/Infrastructure/Phabricator
Sure. Let me compile Breeze with those settings to see if it works on my machine or not and then I'll send a patch.
I registered on that KDE identity site and tried to verify my account but the verification site offers me no username to select. Who do I contact about this? Anyhow, this is how the shadow effect works on my fork. As you can see I have a pronounced outline around the window and additional drop shadow. Both are reduced in intensity once the window loses focus: https://we.tl/t-rWmQbo8Cxq
I'm sorry that the registration process isn't working properly. :( We know that this sucks and we're currently investigating alternatives. Please email sysadmin@kde.org and they should get it fixed up for you pretty quickly.
Do you need a hand with this? If Phab isn't cooperating, you can just attach a patch file here.
Created attachment 123604 [details] attachment-16199-0.html No I think it's okay. I got a mail from sysadmin but I haven't been at my machine yet. Will work with phab tomorrow. 30. Okt. 2019, 18:48 von bugzilla_noreply@kde.org: > https://bugs.kde.org/show_bug.cgi?id=393238 > > --- Comment #27 from Nate Graham <nate@kde.org> --- > Do you need a hand with this? > > If Phab isn't cooperating, you can just attach a patch file here. > > -- > You are receiving this mail because: > You are on the CC list for the bug. >
After some fiddling I must say it's not as easy as I thought it'd be. The reason why the modification works on my theme is because the theme I used as a base implemented an older shadow rendering method as a library, which makes it possible to create the different shadow strengths. I'm pretty sure a revert to that shadow rendering would fix this issue, but there surely were reasons to move away from that in favor of something else. Library in question can be found here: https://github.com/n4n0GH/breezeway-mod/tree/master/libbreezewaycommon How to proceed?
Debug why it doesn't work in the Breeze window decoration theme, I guess. :/
(In reply to n4n0 from comment #29) > After some fiddling I must say it's not as easy as I thought it'd be. > > The reason why the modification works on my theme is because the theme I > used as a base implemented an older shadow rendering method as a library, > which makes it possible to create the different shadow strengths. > > I'm pretty sure a revert to that shadow rendering would fix this issue, but > there surely were reasons to move away from that in favor of something else. > > Library in question can be found here: > https://github.com/n4n0GH/breezeway-mod/tree/master/libbreezewaycommon > > How to proceed? I don't think that's the case, because the library is exactly the same as the current one (except the KDE4 parts): https://github.com/KDE/breeze/tree/master/libbreezecommon I'm currently working on a fork of Breeze decoration too. I copied the shadow parts from yours, but somehow it doesn't work on mine.
I didn't get around doing too much debugging. But yes, my initial thought that he library was to blame is wrong. I put the *decoration.cpp of the original Breeze and my theme through Kompare and found that my theme creates another type of shadow, along with the default one. I hope to be able to create a proper debugging on friday maybe and post results.
Coded up a version that halves shadow strength for inactive windows. Preview in the merge request. https://invent.kde.org/plasma/breeze/-/merge_requests/33
Very nice! I will take a look soon.
Merge request committed to master, with added animation support. https://invent.kde.org/plasma/breeze/-/merge_requests/33
Thanks Lindsay!
Hi, I noticed this change doesn't work with Firefox for some reason. The shadow always has the same strenght on the Firefox window. Everything else seems to be working. I'm using the latest Neon Unstable edition. I tested with both Wayland and X.
I'll bet a million dollars that you're using Firefox with client-side decorations, for which KWin does not draw the shadow. We'll need a companion change for the breeze-GTK theme, assuming this is possible. I dunno if we can do the animation. Carson, do you think that's possible?
(In reply to Nate Graham from comment #38) > I'll bet a million dollars that you're using Firefox with client-side > decorations, for which KWin does not draw the shadow. Yes, you're right 😅 I noticed something else: I just updated my test system again and I noticed the shadows are not being animated when switching between active and inactive windows. When this patch landed I remember the shadows would fade between the different states. Plasma version is 5.20.80.
Yes, we briefly had animation, but it got lost with https://invent.kde.org/plasma/breeze/-/commit/a9ac9578a9180788d56e6d92fe647075a2afc0d2. We need to re-do that to only disable the background color animations, not all animations.
Drop shadows are a kind of thing that represents light source. It looks really off to have some windows have shadows and some not. Is there a setting or config file setting that can allow all windows to have uniform shadows?