Le 19/1/2009, Giovanni Bajo ra...@develer.com a écrit:
This would work on Qt4 as well, but of course it's not ideal as you need
a timer to poll the queue. It's much easier to use QThreads and simply
post the events (or use the asynchronous signals).
Plus, you can now do non-trivial things
On Tue Feb 3 10:28:26 GMT 2009, Giovanni Bajo wrote:
The trick is that a signal/slot connection across a thread is different
from a normal one: in a normal connection, slots are called immediately,
within the emit() call. Instead, in an asynchronous connection, when
the signal is emitted, an
Le 3/2/2009, Giovanni Bajo ra...@develer.com a écrit:
PS: does it already exist a simple solution to adapt this code:
thread = threading.Thread(target=func)
thread.start()
using QThread?
Yes: QtConcurrent::run.
:o)
Thank you all for your help!
--
Frédéric
Le 3/2/2009, Giovanni Bajo ra...@develer.com a écrit:
The trick is that a signal/slot connection across a thread is different
from a normal one: in a normal connection, slots are called immediately,
within the emit() call. Instead, in an asynchronous connection, when
the signal is emitted, an
A Dimarts 03 Febrer 2009, Frédéric va escriure:
PS: does it already exist a simple solution to adapt this code:
thread = threading.Thread(target=func)
thread.start()
using QThread?
Not that I know of, but it's trivial to implement. Something like this should
do:
class
On mardi 03 février 2009, Giovanni Bajo wrote:
In this last case, does the call to emit() immediatly return, and the
thread go on with the next instruction, or does it wait until the
event has really called the slot?
Depends on the connection type (which you can manually specify during
On 2/3/2009 5:17 PM, Frédéric wrote:
On mardi 03 février 2009, Giovanni Bajo wrote:
Notice that it's easy to deadlock, if you don't pay enough attention (and
even if you do ;).
Why do you say it is easy to deadlock? Do you mean that Qt can do
unexpected things?
No: I meant that a
On 2/3/2009 12:24 PM, Frédéric wrote:
Le 3/2/2009, Giovanni Bajo ra...@develer.com a écrit:
The documentation says that a QPainter can only paint on QImage, QPrinter
and QPicture, but not on QWidget and QPixmap (it seems that painting on
QGraphicsItem works fine, as I don't have warnings; can
On mar, 2009-01-20 at 12:08 +0800, Christoph Burgmer wrote:
Am Tuesday, 20. January 2009 schrieb Giovanni Bajo:
On 1/19/2009 4:36 PM, Christoph Burgmer wrote:
[...]
I am doing a
QCoreApplication.postEvent()
out of run() from a threading.Thread class without any
Am Monday, 19. January 2009 schrieb Giovanni Bajo:
On 1/19/2009 3:13 PM, eliben wrote:
I've seen various references to this issue before, but nothing to fully
address it as I'd expect.
Can you comment on the pros and cons of using QThread vs Python's threads
with PyQt?
I'll begin:
Le 19/1/2009, Christoph Burgmer chri...@gmx.de a écrit:
I am doing a
QCoreApplication.postEvent()
out of run() from a threading.Thread class without any problems.
Under which plateform?
--
Frédéric
___
PyQt mailing list
Hi,
I always used QThread and emit() in order to communicate with main
QThread without problems:
thread = Thread(self)
self.connet(thread, SIGNAL(Signal))
thread.start()
2009/1/19 Christoph Burgmer chri...@gmx.de:
Am Monday, 19. January 2009 schrieb Giovanni Bajo:
On 1/19/2009 3:13 PM,
Sorry!
thread = Thread(self)
self.connet(thread, SIGNAL(Signal), self.Slot)
thread.start()
2009/1/19 Sergio Jovani lese...@gmail.com:
Hi,
I always used QThread and emit() in order to communicate with main
QThread without problems:
thread = Thread(self)
self.connet(thread, SIGNAL(Signal))
Am Monday, 19. January 2009 schrieben Sie:
Le 19/1/2009, Christoph Burgmer chri...@gmx.de a écrit:
I am doing a
QCoreApplication.postEvent()
out of run() from a threading.Thread class without any problems.
Under which plateform?
Linux.
I initially made a short check if their was any
On lundi 19 janvier 2009, Christoph Burgmer wrote:
QCoreApplication.postEvent()
out of run() from a threading.Thread class without any problems.
Under which plateform?
Linux.
I initially made a short check if their was any argument against using
Python threads with Qt and then
On 1/19/2009 4:36 PM, Christoph Burgmer wrote:
Am Monday, 19. January 2009 schrieb Giovanni Bajo:
On 1/19/2009 3:13 PM, eliben wrote:
I've seen various references to this issue before, but nothing to fully
address it as I'd expect.
Can you comment on the pros and cons of using
On 1/19/2009 5:03 PM, Christoph Burgmer wrote:
Giovanni's response strikes me as it would be a serious annoyance if I
had to change my threading model only to port my application to Windows
and Mac. I don't even get any QPainter or other thread related warnings
in my app, something which KDE
On 1/19/2009 5:37 PM, Frédéric wrote:
I use python threads, but I have a serializer to push all Qt calls on a
queue, and this queue is processed from the main thread, using a QTimer
timeout signal.
This would work on Qt4 as well, but of course it's not ideal as you need
a timer to poll the
On lundi 19 janvier 2009, Giovanni Bajo wrote:
On 1/19/2009 5:37 PM, Frédéric wrote:
I use python threads, but I have a serializer to push all Qt calls on
a queue, and this queue is processed from the main thread, using a
QTimer timeout signal.
This would work on Qt4 as well, but of
Am Tuesday, 20. January 2009 schrieb Giovanni Bajo:
On 1/19/2009 4:36 PM, Christoph Burgmer wrote:
[...]
I am doing a
QCoreApplication.postEvent()
out of run() from a threading.Thread class without any problems.
That's only because you are lucky. It's not something that's officially
20 matches
Mail list logo
