On Monday 11 September 2017, @dhaumann wrote:

3c5b1bc

No luck with this, anyone an idea?

My gut feeling is that

• qWaitForWindowExposed is the wrong thing to use and we are observing a weird race between showing the label for the first time, setting the property and some resizing, which has different winners on local tests vs. the CI (try adding a qWaitForWindowExposed before setProperty: now it fails even locally)
• removing the Q_PROPERTIES in D7164#144208 was too fast (imagine a fixed size policy, where no resize happens: we now miss calling squeezeTextToLabel for e.g. setIndent)
• we need a better understanding in which situations a resize event occurs (the test currently assumes we need to manually call adjustSize, but I think this is wrong)

More things to think about:

• minimumSizeHint feels wrong, maybe it should also account for the chrome widths?
• the size policy Expanding set in the constructors seems strange, shouldn't it be Preferred as set in the autotests? (but changing this might break assumptions)
• we need to do more testing regarding different size policies, also in comparison to QLabel (no matter what size policy, Qt only called minimumSizeHint for me, to trigger sizeHint I would always need to call adjustSize manually – but maybe my test was just flawed)

TL;DR: This will take some time, more investigations and maybe review requests needed.

xvfb-run -s '-screen 0 800x600x24' ksqueezedtextlabelautotest reproduces the CI failure for me (passes without xvfb). Maybe that's because there's no window manager running there.

Anyway, we should fix the test to deal with that and not the other way around. At least we now have a way to test locally.

Results of the investigation:

• qWaitForWindowExposed was wrong, it only masked the real problem locally
• When the label is not able to resize in a given layout and setIndent or other calls further reduce the space available, we have to react by squeezing the text. Therefore, a custom setIndent is needed for real. Concerns regarding BC can probably be countered by checking with abi-compliance-checker.
• Respecting the chrome also in minimumSizeHint is feasible and should add some polish and sensible behaviour to the default minimum widths.
• Regarding the comparison of resize handling with QLabel, it is a design decision whether we should react to changes by resizing or squeezing. After looking through the commit history and early applications, I could imagine the original authors had the following in mind (e.g. a statusbar frame of a browser displaying the link hovered over or the file name in a status dialog of a directory copying action): The label is placed in a layout, where the actual text to display is not known yet. Therefore it makes sense to give the label as much space as possible (i.e. Expanding size policy). Now the displayed text is changed quite often over the course of the lifetime of the application. Here it is reasonable to keep the size as is to avoid flickering (i.e. squeeze by default, adjustSize needs to be called manually). In summary: No changes needed, but this could be added to the documentation.
• Testing all different size policies, no errors could be found and all resizing was in accordance to the docs (the trick was to display a frame, to differentiate between window and label and not get confused). It is worth noting that for Fixed, Minimum and MinimumExpanding text will never be squeezed (by design as well as implementation).

I'll start with fixing the CI-failing autotest, with further improvements following as time permits. I also have an idea how to argue regarding D7010. If anyone has any thoughts or critique about these findings, the planned actions or additional pain points with KSqueezedTextLabel in the meantime, please share.