[prev in list] [next in list] [prev in thread] [next in thread] 

List:       pykde
Subject:    Re: [PyKDE] Updating GUI from another thread
From:       "Giovanni Bajo" <rasky () develer ! com>
Date:       2005-04-07 7:47:53
Message-ID: 047f01c53b46$1ad5dce0$71422597 () bagio
[Download RAW message or body]

Jeffrey Barish <jeff_barish@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().

> 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

_______________________________________________
PyKDE mailing list    PyKDE@mats.imk.fraunhofer.de
http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
[prev in list] [next in list] [prev in thread] [next in thread]