[PyKDE] Re: Updating GUI from another thread

[Jeffrey Barish]

Giovanni Bajo wrote:

> Jeffrey Barish <jeff_barish at earthlink.net> wrote:
> 
>> I tried using
>> a custom event.  I found that I need a timer in the GUI thread to
>> trigger a processEvents call.
> 
> The timer should not be needed at all: the main thread is sitting in
> the event loop, so there is no reason why you need to call
> processEvents().
> 
That's what I expected, but without the call to processEvents the GUI
doesn't update unless I do something (e.g., scroll the item out of the
display or maximize/restore) to trigger an update.  My test program
displays this behavior too.  Just comment out the timer start
statement.  Clicking on the minimize button is sufficient to get the
window to updte even though it doesn't minimize.

>> Then I discovered that I don't seem to
>> need the custom event: I can simply deselect the item from the task
>> thread, although the processEvents call is still necessary.  Is the
>> issue that something bad could happen if I happen to try selecting
>> the item at the same time the task thread is trying to deselect it?
> 
> Yes, you should not be doing this. If you really need this, you must
> use app.lock() / app.unlock() in the thread to block the main thread.
> 
> Basically, in Qt 3, the only safe thing you can do is sending a custom
> event across threads. In Qt 4 you can connect signals/slots across
> threads (across QThreads actually) and Qt will do the right thing.
> 
>> Is the solution with the custom event optimal?
> 
> Yes, without QTimer. You should not need it.
> 
> Giovanni Bajo

-- 
Jeffrey Barish