splash screen problem

[high_flyer]

Then he's accessing widgets from a non-gui thread. So it's still no ok.

how do you come to that conclusion?
He could be very well in the Gui thread calling the non gui thread's sleep... (provided if overriden it to be public)
Or am I missing something?

To original poster:
You should explain a bit what you are doing, we can't just guess!

[squidge]

Could be, but I don't see why you'd call a sleep function on a different thread. Surely the point of the call is to delay the execution of the current thread so that the splash screen stays up longer, and if he's doing that, he can't be processing messages too.

[wysota]

how do you come to that conclusion?
He could be very well in the Gui thread calling the non gui thread's sleep... (provided if overriden it to be public)
Or am I missing something?

Several reasons. First of all I don't think you can put thread A to sleep from thread B. Second of all Utils::sleep() is a static call so unless Utils is a singleton class, it is likely that its behaviour is similar to QThread::sleep() which puts the current thread to sleep. Furthermore if it was the case that this call puts another thread to sleep then calling sleep() several times in a row wouldn't make any sense as the thread would already be sleeping after the first call.

[high_flyer]

First of all I don't think you can put thread A to sleep from thread B.

You could if you exposed sleep() and internally make the thead call its own sleep. (I wouldn't, you niether, but who knows? I have seen stranger things!)

Second of all Utils::sleep() is a static call so unless Utils is a singleton class, it is likely that its behaviour is similar to QThread::sleep() which puts the current thread to sleep.

That is a good point, which wraps it for me.
If Utils is a mother class, than he is putting him self to sleep.
If not, then its something like what I just wrote above, which is probably even worse.

Furthermore if it was the case that this call puts another thread to sleep then calling sleep() several times in a row wouldn't make any sense as the thread would already be sleeping after the first call.

Ah... how many times have we seen here stuff that doesn't make any sense?

[wysota]

You could if you exposed sleep() and internally make the thead call its own sleep. (I wouldn't, you niether, but who knows? I have seen stranger things!)

You mean like "schedule a sleep"? Maybe... But I don't think that's the case here

Ah... how many times have we seen here stuff that doesn't make any sense?

I tend to assume that something someone did does make some sense until I have enough evidence or intuition to say otherwise.

Anyway, the solution is to use a timer instead of the sleep calls. And signals and slots, of course.