Hi again!
On Dienstag 21 Oktober 2008, Dirk Meyer wrote:
> Twisted has an event triggered at shutdown. The Twisted based threaded
> notifier connects to that signal and shuts the kaa loop down:
> | reactor.addSystemEventTrigger('after', 'shutdown', self.stop)
>
> So just call the stop function and it should work.
Ah, that works. I thought that kaa.main.stop() should do the trick. If I
store the result of initializing the notifier and call stop on the ThreadLoop
object instead, it works:
loop = kaa.main.select_notifier(
'thread', handler = call_from_qt_mainloop,
shutdown = stop_app_if_running)
QtCore.QObject.connect(_qapp, QtCore.SIGNAL("aboutToQuit()"),
loop.stop)
But shouldn't kaa.main.stop() work, too? (I thought the latter was the public
API for stopping the loop, irrespectively of how it was initialized.) Ah,
now I see that it indeed works, since I provided a "shutdown" callback which
calls QCoreApplication.quit, which emits the aboutToQuit signal, which I
connected to the loop.stop.
Ctrl-C works, too. Everything's fine, obviously.
> > Yes, I realized already that I needed a much more complicated solution
> > than with twisted. But IMO that's just because of different APIs, and
> > "execute a callback in the [main thread's] mainloop" is not a very
> > typical requirement (maybe more so in a python environment, but not in
> > C++).
>
> IMHO it has nothing to do with the language. If you have a main loop
> based app you may be forced to use a thread somehow. If the lib is
> thread safe this doesn't matter, if it is not, such a function must be
> provided. E.g. gobject is thread-safe. It has no such function but I can
> register a timer from a thread and just add my callback as timer to be
> called in 0 seconds. That timer will be called from the mainloop.
You can do the same in Qt; here, every thread has its own event loop, and
every object has a certain thread affinity (inherited from its parents). You
can then connect the "timeout()" signal of the timer to the slot of any
object, and the slot will be called within the thread associated with that
object. The glue code is only necessary because the thread uses a pythonic
API. It would be much simpler if I used the Qt API within the thread, too
(e.g. by letting ThreadLoop inherit from QThread instead of
threading.Thread). I mentioned "language" because in C++, in the absence of
(built-in) bound member functions and closures, one would not model this with
a *callback* (i.e. global, static functions), but with real objects, which is
what Qt basically does.
But now the glue code is written and works.
--
Ciao, / / .o.
/--/ ..o
/ / ANS ooo
test_qt_mainloop.py
Description: application/python
kaa_in_qt.py
Description: application/python
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________ Freevo-devel mailing list Freevo-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freevo-devel
