hpereiradacosta added a comment.
In https://phabricator.kde.org/D10170#199003, @fredrik wrote: > > I think the "blur" option should go. Blur should be controlled centrally by the desktop effect. In other words: BlurBehind should always be set to true, and then left to kwin to handle. Having an extra option here seems like micro-management. Why would you need blur behind plasma widgets (as handled by the desktop effect) and not behind menus ? (or vice versa). Also, right now, selecting "blur" in the style settings, but unselecting the desktop effect results in no blur behind menu, and hence inconsistency with what the style option says. > > KWin has no way of knowing which pixels should be blurred behind a window. That's the reason the hint exists. > If you set the hint unconditionally, the effect will be applied unconditionally. Even when the menus are fully opaque. Correct. So the call to enableBlurBehind should be made only if "asAlphaChannel" _and_ opacity < 1 This still does not need an extra option. Added comment in the code about this. Thanks for the clarification. INLINE COMMENTS > breezestyle.cpp:3630 > + #if !BREEZE_USE_KDE4 > + KWindowEffects::enableBlurBehind(widget->winId(), true); > + #endif This should be called only if StyleConfigData::menuOpacity() is < 100 And in fact, I wonder if it is safe to make the call at every painting call. I guess it depends on how the underlying function is implemented (does it first check for the property ?) REPOSITORY R31 Breeze REVISION DETAIL https://phabricator.kde.org/D10170 To: anemeth, hpereiradacosta, #plasma, colomar, alake Cc: fredrik, alake, januz, abetts, colomar, andreask, zzag, ngraham, plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, jensreuterberg, sebas, apol, mart
