Open AlexFolland opened 3 months ago
The small thing in the corners looks like a glitch, does it show all the time?
If I understood you correctly you want to achieve something like this?
This preset does exactly that for me issue64panelColorizerConfig.txt
Can you save and share yours then try the one above? Presets are saved in ~/.config/panel-colorizer/
One thing to note is that (as stated in the settings) forcing a fixed side padding is somewhat buggy so achieving this look in a panel that doesn't fill the height/width of the screen is not possible right now, hopefully I will find a solution for that when I get around doing the rewrite.
In fact, you can see the issue in your screenshot. You're using a dark background so it's harder to see, but if you put a lighter background on, you can see it just below the KDE icon and also just above the clock. Here's a picture of the issue in a zoomed-in image of your screenshot. Sorry it's blurry, but KDE Plasma doesn't switch to nearest-neighbor scaling when it zooms in like XFCE does. I need to report that to KDE devs.
Looks like we have a similar configuration and both have the issue. It's just particularly easy to see in my setup because I had a very bright background and absolutely black widget backgrounds.
Okay, I see it on my screen now, not sure how I didn't notice before as I use bright wallpapers sometimes.
This seems to be a rendering problem related to Kirigami's ShadowedRectangle
(https://github.com/KDE/kirigami/blob/master/src/primitives/shadowedrectangle.cpp) which is what I use to draw the widget/panel background with shadows and rounded corners.
Wrote two small examples to simulate the panel and the Kirigami ShadowedRectangle
type has this problem while the regular rectangle doesn't.
Setting the border width to -1 makes the glitch go away (or at least I don't see it with my monitor/eyes), maybe there's some miscalculation somewhere related to the borders???
import QtQuick
import QtQuick.Layouts
import org.kde.kirigami as Kirigami
Rectangle {
width: 300; height: 200
property color bgColor: "#ffffff"
property color rectColor: "#323232"
Rectangle {
color: bgColor
anchors.fill: parent
ColumnLayout {
anchors.fill: parent
Text {
text: "Kirigami.ShadowedRectangle"
}
GridLayout {
height: 40
width: parent.width
columnSpacing: 0
Repeater {
model: 6
delegate: Kirigami.ShadowedRectangle {
id: kirigamiShadowedRectangle
Layout.preferredHeight: parent.height
Layout.fillWidth: true
color: rectColor
border {
width: 0
color: "white"
}
}
}
}
Text {
text: "Kirigami.ShadowedRectangle border: -1"
}
GridLayout {
height: 40
width: parent.width
columnSpacing: 0
Repeater {
model: 6
delegate: Kirigami.ShadowedRectangle {
id: kirigamiShadowedRectangle
Layout.preferredHeight: parent.height
Layout.fillWidth: true
color: rectColor
border {
width: -1
color: "white"
}
}
}
}
Text {
text: "Rectangle"
}
GridLayout {
height: 40
width: parent.width
columnSpacing: 0
Repeater {
model: 6
delegate: Rectangle {
id: qtRectangle
Layout.preferredHeight: parent.height
Layout.fillWidth: true
color: rectColor
}
}
}
}
}
}
This kind of positional texture issue is common with graphics programming because there are many programmers who don't know the positioning of what's called "texels" in relation to screen pixels in modern graphics APIs. The edge points on these texels are actually in the middle of pixels, so if whole numbers are used instead of offsetting those whole numbers by 0.5 for mapping the texels, the texel squares don't accurately match the positions of the pixels, and so the edges end up being rasterized as half the neighboring color. The following article demonstrates the issue and explains what I'm talking about visually, at least in relation to Direct3D 9: Directly Mapping Texels To Pixels (Direct3D 9).
I'm actually just guessing it's similar with OpenGL and Vulkan, or whatever is being used in this case in KDE Plasma Wayland. I've seen similar issues many times in many places and I'm guessing it's because so few programmers understand this (and even I was lucky to stumble across that article back in 2011 when trying to help the RetroArch devs with the D3D9 renderer for Windows).
Regardless of what is actually causing the issue, thanks for acknowledging the issue.
By the way, I tried to set border ("Outline" in the Panel Colorizer Widget background settings) width to -1, but that edit box rejects negative number input, so I can't use the workaround you mentioned for now.
Setting a widget outline width of 1 with the same color as the widget background (custom color black, in my case) and full opacity (1.00) does work around the issue. I'll be using that workaround for now then.
Reopening because the hack of setting the border to -1 wasn't a very good idea as it causes some other sizing issues.
Did github just re-close this with the same commit from before?
My bad, reopening.
I think this was incorrectly auto-closed by the reverted commit again, this time as part of a release message.
oops
I have panel background hidden, padding set to 0, and widget background enabled, except for the spacer. This is so that I can see part of my desktop background (or any full-screen program) in the unused space. That all works, but there are these thin seams which are especially visible in the corners of the widgets. Here's a screenshot.
Just to clarify, the expected behavior is to have no seams and square corners so that the fact that there's a background on each widget instead of the overall panel is not visible.