PyQT: pausing an application for the next event

[Srinath Avadhanula]

Hello,

[Python 2.3 + QT 2.3.0 + PyQT 3.8.0-nc]

I am wondering if QT has something like QWaitForNextEvent() function.
This function would block execution of the application till another key
was pressed and then return the event which occured.

Would like to utlize this in a small application I am building:
I am trying to create vi key-bindings for a simple QMultiLineEdit
control. I created a class which overloads the QMultiLineEdit class
and then re-defined its keyPressEvent() function. If something like
QWaitForNextEvent() were available, I would have done something like the
following:

def MySimpleVi(QMultiLineEdit):
def keyPressEvent(self, event):
if event.text() == 'd':
self.deleteLine(event)

def deleteLine(self, event):
count = 0
movement = None

nextevent = QWaitForNextEvent()
while iscount(nextevent):
count = 10*count + int(nextevent).text
nextevent = QWaitForNextEvent()

if ismovement(nextevent):
movement = nextevent.text()

range = calculateRange(self.getCursorPosition(), movement, count)
self.deleteRange(range)

Without a function like QWaitForNextEvent(), I will have to make
deleteLine() somehow remember its state between successive calls. I will
also have to make the keyPressEvent() function remember state between
calls so that it can keep passing events to deleteLine() till
deleteLine() is "done". Such things will get even more complex if I plan
to implement vi commands like "3d3j", which take an optional count
before the command description and then execute the command so many
times.

Any advice/suggestions would be greatly appreciated.

If PyQT does not have something like this, is there some completeley
different way to accomplish something similar? Basically have a function
pause between successive calls and resume from last time but with one of
the local variables corresponding to the function arguments changed?
This sounds a little like generator functions in Python, but I cannot
think of a way to use them here.

I searched the QT-interest mailing list and found this to be of
interest:

http://lists.trolltech.com/qt-interest/2000-10/thread00270-0.html

However, as Mr. Peter Becker says after offering a solution:

But my last experiences using such techniques taught me: don't use
such stuff if you can avoid it. You can run in different kinds of
deadlocks and livelocks -- I even got a reproducable Zombie this way
(NT showed a running process without task). Plus: to much calling of
QApplication:rocessEvents() seems to result in big CPU load.


Thanks,

Srinath

 

[Phil Thompson]

Hello,

[Python 2.3 + QT 2.3.0 + PyQT 3.8.0-nc]

I am wondering if QT has something like QWaitForNextEvent() function.
This function would block execution of the application till another key
was pressed and then return the event which occured.

Would like to utlize this in a small application I am building:
I am trying to create vi key-bindings for a simple QMultiLineEdit
control. I created a class which overloads the QMultiLineEdit class
and then re-defined its keyPressEvent() function. If something like
QWaitForNextEvent() were available, I would have done something like the
following:

def MySimpleVi(QMultiLineEdit):
def keyPressEvent(self, event):
if event.text() == 'd':
self.deleteLine(event)

def deleteLine(self, event):
count = 0
movement = None

nextevent = QWaitForNextEvent()
while iscount(nextevent):
count = 10*count + int(nextevent).text
nextevent = QWaitForNextEvent()

if ismovement(nextevent):
movement = nextevent.text()

range = calculateRange(self.getCursorPosition(), movement, count)
self.deleteRange(range)

Without a function like QWaitForNextEvent(), I will have to make
deleteLine() somehow remember its state between successive calls. I will
also have to make the keyPressEvent() function remember state between
calls so that it can keep passing events to deleteLine() till
deleteLine() is "done". Such things will get even more complex if I plan
to implement vi commands like "3d3j", which take an optional count
before the command description and then execute the command so many
times.

Any advice/suggestions would be greatly appreciated.

If PyQT does not have something like this, is there some completeley
different way to accomplish something similar? Basically have a function
pause between successive calls and resume from last time but with one of
the local variables corresponding to the function arguments changed?
This sounds a little like generator functions in Python, but I cannot
think of a way to use them here.

I searched the QT-interest mailing list and found this to be of
interest:

http://lists.trolltech.com/qt-interest/2000-10/thread00270-0.html

However, as Mr. Peter Becker says after offering a solution:

But my last experiences using such techniques taught me: don't use
such stuff if you can avoid it. You can run in different kinds of
deadlocks and livelocks -- I even got a reproducable Zombie this way
(NT showed a running process without task). Plus: to much calling of
QApplication:rocessEvents() seems to result in big CPU load.

The (now obsolete) QApplication.processOneEvent() is probably the nearest -
but it processes the event and does not return it for you to process the way
you want to. Also, as the documentation says "Using this function in new
applications may be an indication of design problems."

Your code seems to make assumptions about what event is expected next. Events
are asynchronous and used for all sorts or things.

What's wrong with keeping state information? Handling an optional prefix
hardly complicates things much.

Phil

 

[Srinath Avadhanula]

[replying to my own email]

It turns out that using generators in python, we can build an equivalent
of the fictional QWaitForNextEvent (which blocks execution till an event
occurs and then returns the event), using generator functions in python.
It is quite cool.

For example, the code

which uses a fictional QWaitForNextEvent() could have been written
without it using generator functions as:


Pretty elegant if I say so myself. The deleteLine() function did not
have to change at all! Ofcourse, without the generator methodology, I
would have had to make things much more complex looking and generally
obfuscated. Hail Python's generators!!!

This is ofcourse completely untested yet. It also hinges on the fact
that if the parent function changes self.nextevent, the generator
function sees the new value in the next iteration and not just the
cached value or something of the sort (actually just verified that the
correct thing indeed happens)...