Review Request: Fix KCategorizedView race

Thomas Lübking thomas.luebking at
Thu Dec 8 18:04:17 GMT 2011

This is an automatically generated e-mail. To reply, visit:

(Updated Dec. 8, 2011, 6:04 p.m.)

Review request for kdelibs, Rafael Fernández López and Jaime Torres Amate.


Suck this, you little nasty bug >)

It's required to keep the policy down all the time and change the visibility according to it's original at the end.
I was not able to reproduce issues with either systemsettings or plugins.

Tests, anyone?


Also see

QListView::updateGeometries() has it's own opinion on whether the scrollbars should be visible (valid range) or not
and triggers a (sometimes additionally timered) resize through ::layoutChildren()
(the comment above the main block isn't all accurate, layoutChldren is called regardless of the policy)

As a result QListView and KCategorizedView occasionally started a race on the scrollbar visibility, effectively blocking the UI
So we prevent QListView from having an own opinion on the scrollbar visibility by
fixing it before calling the baseclass QListView::updateGeometries() and restoring the policy afterwards

This addresses bugs 213068 and 287847.

Diffs (updated)

  kdeui/itemviews/kcategorizedview.cpp 5e33861 



Yes, resizing the "kcmshell4 kwincompositing", "all effects" KPluginSelector with large scrollbar sizes (bespin/position indicator/32px; oxygen was often sufficient with the default size) after commit e91e5fed6b1aad365e12e919f430c3e8147552d3 (see ) was a reliable way to trigger the issue for me.
It also showed that resize/updateGeometries occured in pairs (ie 4calls forming  a block), what's never happened again with the patch.


Thomas Lübking

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the kde-core-devel mailing list