Re: Test Failures Fatal by Default in KDE CI
On Montag, 17. März 2025 14:54:24 Mitteleuropäische Normalzeit Kristen McWilliam wrote: > ## TLDR > > Test failures will be fatal by default in KDE CI. Use > `allow-failing-tests-on` to opt out temporarily. Review and update your CI > configurations to ensure a smooth transition. Reach out for support if > needed. I wanted to prepare kleopatra for this change, but I guess there's nothing to do for now. kleopatra currently has ``` Options: require-passing-tests-on: ['Linux', 'FreeBSD'] ``` At the moment, there are only builds on Linux and FreeBSD. I was wondering if I can remove `require-passing-tests-on`, but I don't think that's possible because this would make failing tests non-fatal. I suppose I have to wait until phase 2 (Make test failures fatal by default) comes into effect. Correct? Second project: libkleo libkleo currently has ``` Options: require-passing-tests-on: ['Linux', 'FreeBSD'] ``` and there are builds for Linux, FreeBSD, and Windows. I suppose I can safely add ``` allow-failing-tests-on: [ 'Windows' ] ``` now _additionally_ to the require-passing-tests-on. Correct? Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Test Failures Fatal by Default in KDE CI
On 2025-03-18, Ingo Klöcker wrote: > For libkleo we do have Windows CI. But those tests seems green? or are they flaky? /Sune
Re: Test Failures Fatal by Default in KDE CI
On 2025-03-18, Ingo Klöcker wrote: > Options: > require-passing-tests-on: ['Linux', 'FreeBSD'] > ``` > and there are builds for Linux, FreeBSD, and Windows. > > I suppose I can safely add > ``` > allow-failing-tests-on: [ 'Windows' ] > ``` > now _additionally_ to the require-passing-tests-on. Correct? That would at least be the same. Though I guess waiting with that part until we actually have windows CI for it would be better. /Sune
Re: Breeze style problem since Qt 6.8.2
Am 17.03.25 um 23:28 schrieb Albert Astals Cid: El dilluns, 17 de març del 2025, a les 22:50:04 (Hora estàndard d’Europa central), Tobias Leupold va escriure: E-Mail von Albert Astals Cid vom Montag, 17. März 2025, 20:38: Can you bisect in which commit the behaviour was introduced? According to what was said on the Qt forums, it should be those two: https://codereview.qt-project.org/c/qt/qtbase/+/601315 https://codereview.qt-project.org/c/qt/qtbase/+/613831 Oh, right you-re using stylesheets, don't do that :D https://www.kdab.com/say-no-to-qt-style-sheets/ Well, okay ... seems like I have some homework now ;-) But sounds reasonable, I also experienced weird behavior and problems using CSS with Qt. So maybe using a QProxyStyle or such actually would be a better solution. However, we do agree that the (maybe) Breeze issue with the QSpinBoxes should be fixed somehow, don't we?! I think as long as it's possible to mess with CSS, the arguably most-used Qt style (I'm really pretty sure most people see Qt programs using Breeze these days) should look fine. I'd also happily help with that if I can, but the problem is somewhere deep in Qt and/or Breeze, and I have no idea about that style stuff (yet) :-( Cheers, Albert cf. https://forum.qt.io/topic/160958/ Cheers, Tobias
Re: Breeze style problem since Qt 6.8.2
E-Mail von Tobias Leupold vom Montag, 17. März 2025, 22:50:
> E-Mail von Albert Astals Cid vom Montag, 17. März 2025, 20:38:
> > Can you bisect in which commit the behaviour was introduced?
>
> According to what was said on the Qt forums, it should be those two:
>
> https://codereview.qt-project.org/c/qt/qtbase/+/601315
> https://codereview.qt-project.org/c/qt/qtbase/+/613831
>
> cf. https://forum.qt.io/topic/160958/
>
> Cheers, Tobias
Just as a follow-up: It were definitely those two commits that cause the
issue. I just tested it out and patched them away, using qtbase 6.8.2 and the
attached patch. Afterwards, QSpinBoxes look like before, no matter if a style
sheet is set or not.
Maybe we could at least add some workaround to Breeze, even if it's Qt's
fault?!diff --git a/src/widgets/styles/qstylesheetstyle.cpp b/src/widgets/styles/qstylesheetstyle.cpp
index f5981da4593..c89b0614a42 100644
--- a/src/widgets/styles/qstylesheetstyle.cpp
+++ b/src/widgets/styles/qstylesheetstyle.cpp
@@ -5299,9 +5299,7 @@ QSize QStyleSheetStyle::sizeFromContents(ContentsType ct, const QStyleOption *op
#if QT_CONFIG(spinbox)
case CT_SpinBox:
if (const QStyleOptionSpinBox *spinbox = qstyleoption_cast(opt)) {
-if (rule.baseStyleCanDraw()) {
-sz = baseStyle()->sizeFromContents(ct, opt, sz, w);
-} else if (spinbox->buttonSymbols != QAbstractSpinBox::NoButtons) {
+if (spinbox->buttonSymbols != QAbstractSpinBox::NoButtons) {
// Add some space for the up/down buttons
QRenderRule subRule = renderRule(w, opt, PseudoElement_SpinBoxUpButton);
if (subRule.hasDrawable()) {
Re: Test Failures Fatal by Default in KDE CI
On Dienstag, 18. März 2025 10:12:06 Mitteleuropäische Normalzeit Sune Vuorela wrote: > On 2025-03-18, Ingo Klöcker wrote: > > Options: > > require-passing-tests-on: ['Linux', 'FreeBSD'] > > > > ``` > > and there are builds for Linux, FreeBSD, and Windows. > > > > I suppose I can safely add > > ``` > > > > allow-failing-tests-on: [ 'Windows' ] > > > > ``` > > now _additionally_ to the require-passing-tests-on. Correct? > > That would at least be the same. Though I guess waiting with that part > until we actually have windows CI for it would be better. For libkleo we do have Windows CI. Regards, Ingo signature.asc Description: This is a digitally signed message part.
KDE Gear projects with failing CI (master) (18 March 2025)
Please work on fixing them, otherwise i will remove the failing CI jobs on their 4th failing week, it is very important that CI is passing for multiple reasons. Good news: 2 repositories were fixed Bad news: 2 repostories have started failing cantor - NEW * https://invent.kde.org/education/cantor/-/pipelines/913314 * testpython fails messagelib - NEW * https://invent.kde.org/pim/messagelib/-/pipelines/913049 * messageviewer-messageparttheme-rendertest fails Cheers, Albert
Re: Breeze style problem since Qt 6.8.2
E-Mail von Tobias Leupold vom Montag, 17. März 2025, 22:50: > E-Mail von Albert Astals Cid vom Montag, 17. März 2025, 20:38: > > Can you bisect in which commit the behaviour was introduced? > > According to what was said on the Qt forums, it should be those two: > > https://codereview.qt-project.org/c/qt/qtbase/+/601315 > https://codereview.qt-project.org/c/qt/qtbase/+/613831 > > cf. https://forum.qt.io/topic/160958/ ... and as another follow-up: I messed around with this stuff a bit now. Using Qt 6.8.1, when no style sheet is set, sizeFromContents() is requested from Breeze when a QSpinBox should be drawn. It returns QSize(52, 32), and the QSpinBox's height is rendered as 32 px, most probably by the default Qt style class, I didn't find out yet where this happens. If a style sheet is set, QStyleSheetStyle::sizeFromContents() comes into play. But Breeze's sizeFromContents() is not called in this case. The size stays initialized to QRenderRule rule = renderRule(w, opt); QSize sz = rule.adjustSize(csz); which is QSize(36, 20). Later on, (rule.hasBox() || rule.hasBorder() || !rule.hasNativeBorder()) matches, and the size is increased to QSize(48, 32) by sz = rule.boxSize(sz). The resulting QSpinBox is thus also drawn with a height of 32 px (looks like coincidence to me, as Breeze isn't involved at all?!). This changed in Qt 6.8.2: When no style sheet is set, the behavior is the same. Breeze's sizeFromContents() is called, returns QSize(52, 32), and the QSpinBox's height is rendered as 32 px. But as soon as a style sheet is set, QStyleSheetStyle::sizeFromContents() takes over. But it behaves differently now: The initial size is overwritten with what Breeze's sizeFromContents() returns. Which is at this point still a size with the correct height of 32 px. And then, as with 6.8.1, (rule.hasBox() || rule.hasBorder() || ! rule.hasNativeBorder()) matches and the size increased via sz = rule.boxSize(sz). But now not from the initial QSize(36, 20) (which doesn't come from Breeze), but from Breeze's QSize(52, 32), thus resulting in QSize(64, 44). And here we get a QSpinBox that is rendered too tall. I don't have enough insight of all this to decide if Qt doesn't behave correctly here, or if Breeze should do something different. I'm not sure though if Breeze can know at all if QStyleSheetStyle::sizeFromContents() calls its sizeFromContents() (where we would need a modified QSpinBox height to get what we actually want) or if the default style class calls it, where the the size Breeze returns is rendered as-is. However, I hope this helps either the Qt or the Breeze guys to figure out who is responsible here and who is free of guilt ...
