Open stevengj opened 11 years ago
Or alternatively, if the PySide event loop is running, it would be good to prevent PyCall from running its own Qt eventloop. This should be as simple as calling:
pygui_stop(:qt)
PyCall.eventloops[:qt] = Base.start_timer(...)
app["_in_event_loop"] = true
from src/PySide.jl:init()
. (The third line is important for Enthought's libraries, e.g. for Chaco and MayaVi, to let them know that the event loop is running so that plot windows can be opened without blocking.)
Also, a couple of things need to be updated in your qt_doevent
for the latest version of Julia. First, the qt_doevent
routine should now take two arguments (async, status::Int32)
even if it ignores them. Second Base.start_timer
now accepts times in seconds (as a floating-point value) rather than in milliseconds (as an integer).
Also, you can cut down on a bit of overhead by caching the processEvents
Python function object and calling it explicitly with pycall
, specifying the return type, as I do in PyCall. That way you eliminate the overhead of the function lookup and runtime type inference.
In the latest PyCall, you can do
pygui_start(:qt)
to start an asynchronous Qt4 event loop with PySide. Maybe this is useful forPySide.jl
?One issue to be aware of is that if both PySide and PyQt4 are present, PyCall uses the latter. Maybe I should default to PySide instead, if that is the main(?) Python Qt interface going forward? Not sure what the current Python trend is here.
Any other feedback on the PyCall event-loop implementation is welcome.