https://bugs.kde.org/show_bug.cgi?id=395725
--- Comment #60 from Alban Boissard <albanboiss...@gmail.com> --- (Can't remove or edit the previous unfinished comment) I agree, this patch is not a perfect solution, and I agree with Paul McAuley (in comment #44) and Kristopher Ives (in comment#23) about a possible better solution. Note that to solve the issue, the effect subtracts four rounded QRegion to the corners of the QRegion that define the "region to blur" ; it not involve hacky shader tricks. I'm a beginner with C++ and the kde code base, but looking at the code I think a possible pattern could be : - Add four properties for the Kdecoration : - hasRoundedCorners, default to false. - topRoundedCornersRadius, default to 0 - bottomRoundedCornersRadius, default to 0 - hasCustomShape, default to false This could be set in the .json or kcfg file of the Kdecoration, and programmatically changed if needed. - In the blur effect. 1) Check if the window have a CustomShape (provided as a QRegion). If yes, use it. 2) If not, check if the window declares roundedCorners. If yes, remove the corners from the QRegion to be blurred, using the radii provided by the kdecoration. 3) If not, check if the user has set some rounded corners radii directly via the effect ui. If yes, use it. (for compatibility with old deco) 4) If not, do nothing more than the current effect. In the effect ui, the corners radii parameters could be moved in another tab and we can add a check button like : "Force to respect rounded decorations corners. Only usefull for decorations that don't provide the information." I hope it makes sens. I will be very busy for the 10 next days, but after that I can submit a fix for point 3). (If somebody as time to do that before me, he's welcome !) Adding the ability to manually set the corners radii seems to not compromise the possibility to do it directly in the deco later. -- You are receiving this mail because: You are watching all bug changes.
