On 26/01/16 10:37, Dmitry Shachnev wrote: > My point was that Qt main loop is usually used on Windows / OS X but *not* > on Debian. Here, Qt is compiled with GLib support and will use GLib main > loop unless explicitly asked not to do so (via QT_NO_GLIB=1 env variable). > That is a very rare use case and I don't see why one will ever need it.
Am I right in thinking that Qt programs always the same external-facing main-loop API, and that results in callbacks being scheduled from GLib's GMainContext on Debian under normal circumstances, or from Qt's built-in equivalent of GMainContext/libevent/etc. on Windows, OS X, or with QT_NO_GLIB? dbus-python needs two things to work with a particular main-loop: it needs to be told how to make that main-loop monitor libdbus connections (a dbus.mainloop.* module), and the application author needs to actually be iterating that main-loop. For GLib, dbus.mainloop.glib is bundled with dbus-python, but the application author also needs to iterate the GLib main-loop via PyGI, either directly or by using a higher-level API like Gtk or GApplication. For Qt, dbus.mainloop.whatever replaces dbus.mainloop.glib (but on Debian, dbus.mainloop.glib would also work), and QApplication replaces PyGI (but on Debian, PyGI would also work). The "main loop" terminology for the dbus-python addons is perhaps unfortunate; it's really more like "event dispatcher integration glue". > If you don't remove these packages from Recommends, then at least please > replace them with their modern PyQt5 alternatives, i.e.: > > python-qt4-dbus â python-dbus.mainloop.pyqt5 > python3-dbus.mainloop.qt â python3-dbus.mainloop.pyqt5 I've done that in git for now, while we decide whether to remove them altogether. S -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk