KSqueezedTextLabel: Investigate resize handling to fix failing autotest
Closed, ResolvedPublic



D7163 and D7164 introduced autotests and fixes in R236 KWidgetsAddons/KSqueezedTextLabel for handling properties like indent. While the autotests (e.g. ksqueezedtextlabelautotest testChrome:indent) pass locally, they fail on the CI.
While investigating the reason for this seems interesting, the problem might also be in the test, i.e. a misunderstanding of resize event handling or a sideeffect of a bug in KSqueezedTextLabel itself.


  • reproduce locally
  • fix failing autotests
  • check resize handling and size policies
  • document and/or fix bugs

Action Items

rkflx created this task.Sep 11 2017, 11:30 PM

On Monday 11 September 2017, @dhaumann wrote:


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.

rkflx added a comment.Sep 14 2017, 7:01 PM

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.

rkflx updated the task description. (Show Details)Sep 14 2017, 7:01 PM
rkflx added a comment.Sep 23 2017, 9:49 PM

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.

rkflx updated the task description. (Show Details)Sep 23 2017, 9:50 PM
rkflx updated the task description. (Show Details)Sep 30 2017, 6:35 AM
rkflx closed this task as Resolved.Aug 24 2018, 10:46 PM