@ ui->statusBar->showMessage("hello", 4000);
Now start top or htop. Funny eh? One core is busy performing an infinite loop (while the gui stays responsive).
I came across this behaviour when I was too lazy to implement an additional "clearMessage" signal in a class that needs to communicate with the statusBar. So I figured I'd be damn smart and just let it show an empty message with timeout 1 (millisecond), so it'll properly clear right at the next event loop cycle. It bit me.
I've looked at "qstatusbar.cpp":http://qt.gitorious.org/qt/qt/blobs/4.8/src/gui/widgets/qstatusbar.cpp#line595, and the problem's source is that they're handling the timeout really strange. They have a QTimer member (d->timer) which is created and deleted when showMessage/clearMessage is called. The timer timeout signal is connected to clearMessage. The problem is, that when you set an empty string, while another non-empty string is still in its showing interval, the timer never gets deleted. Because clearMessage immediately returns when the string is empty - without even checking whether there's a timer to delete. So basically you've got this rabid 1ms-timer having a party in the event loop.
Now: Would you consider this a Qt bug or is it my fault for „misusing showMessage“ (although the docs don't warn me)? If so, is it any use reporting this? I mean I'm sure there are thousands of reports waiting to get fixed. On the other hand all you'd need is to either not only check whether the string is empty, but also whether the d->timer is 0. Or just d->timer->setSingleShot(true). Or better yet, quit this nonsense d->timer business, and just call QTimer::singleShot(timeout, this, SLOT (clearMessage())) in showMessage.
Further, do I need a gitorious account to report a bug or even submit a patch or is there a way to do it anonymously (with proper patch inspection before applying it, obviously, but that should happen anyway)?