Created attachment 162966 [details] Screenshow showing the offset. SUMMARY In the system monitor header, there is a slight offset, see screenshot attached. Possibly caused by https://invent.kde.org/plasma/breeze/-/merge_requests/342 ? STEPS TO REPRODUCE 1. Open plasma systemmonitor 2. See offset. 3. OBSERVED RESULT Pixel offset, see screenshot. EXPECTED RESULT No offset. SOFTWARE/OS VERSIONS Linux/KDE Plasma: neon-unstable-20231107-1001.iso KDE Plasma Version: 5.27.80 KDE Frameworks Version: 5.240.0 Qt Version: 6.6.0 ADDITIONAL INFORMATION
Can reproduce.
Can reproduce but only after updating Kirigami to master, which seems to indicate that the issue is there. Particularly since there has been a few commits touching the AbstractApplicationHeader in the last few days (e.g. c0a0ab0861fdbda2bfecfb78de14fde40282b0f0)
> Can reproduce but only after updating Kirigami to master, which seems to indicate that the issue is there. Particularly since there has been a few commits touching the AbstractApplicationHeader in the last few days (e.g. c0a0ab0861fdbda2bfecfb78de14fde40282b0f0) I reverted for testing, and it was not the cause. The cause is https://invent.kde.org/frameworks/qqc2-desktop-style/-/commit/bf544dd825d08ce39115f1f7f5f044af3e200cc7
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/qqc2-desktop-style/-/merge_requests/319
Git commit cc0ec4ae33599f92365cfd88d8c2e939d7fdd871 by ivan tkachenko. Committed on 14/11/2023 at 00:18. Pushed by ratijas into branch 'master'. ToolBar: Fix layout of background, strip out duplicated heuristics on position The approach adopted in bf544dd825d08ce39115f1f7f5f044af3e200cc7 did not account for separator's height in its margins-based solution; and overall it didn't quite work anyway, because bottomMargin does nothing without a bottom or fill anchor set. Soit resulted in a bug where separator would stick out of header's boundaries, effectively being misaligned with an application header. This patch resolved the issue by assigning anchors one by one imperatively in a boring but reliable way. And a state machine, in my opinion, would've been too heavy for a control which is not even supposed to change position state during its lifetime under normal circumstances. Speaking of boring ways, interestingly, QML Engine allows writing this: required property T.ToolBar control control.onPositionChanged: __fixup() but for some reason it does amusingly nothing, so let's stick to the usual Connections object. Apart from that, reduces duplicates of heuristics about position based on assumed parent.footer property, and fixes the only one left so it does not cause noise in console when a ToolBar's parent doesn't have a relevant property in it. In fact, I'm against having any heuristics here at all, as it would mask some subtle bugs for 3rd party developers that might also want to run with other QQC2 themes. M +11 -19 org.kde.desktop/ToolBar.qml A +52 -0 org.kde.desktop/private/DefaultToolBarBackground.qml [License: GPL(v2.0+) LGPL(v3.0)] https://invent.kde.org/frameworks/qqc2-desktop-style/-/commit/cc0ec4ae33599f92365cfd88d8c2e939d7fdd871