##// END OF EJS Templates
Backport PR #2294: inputhook_qt4: Use QEventLoop instead of starting up the QCoreApplication...
Backport PR #2294: inputhook_qt4: Use QEventLoop instead of starting up the QCoreApplication I referenced this branch in #2080 and was letting it sit for a little while, but I have decided to make it a full pull request to get some additional visibility. Essentially our Qt event loop mechanism repeatedly starts and quits a `QCoreApplication` object. Unfortunately the `QCoreApplication::quit` slot has a lot of unintended side effects (like emitting an `aboutToQuit` signal which closes all open file dialogs). For our input hook, we _might_ be able to get by with just using a `QEventLoop` whose quit slot is much simpler and less destructive. For a little bit of background on why one might want to just use `QEventLoop::exec`, let's examine what `QCoreApplication::exec` does: ```c++ int QCoreApplication::exec() { if (!QCoreApplicationPrivate::checkInstance("exec")) return -1; // ... [some assertions] threadData->quitNow = false; QEventLoop eventLoop; self->d_func()->in_exec = true; self->d_func()->aboutToQuitEmitted = false; int returnCode = eventLoop.exec(); threadData->quitNow = false; if (self) { self->d_func()->in_exec = false; if (!self->d_func()->aboutToQuitEmitted) emit self->aboutToQuit(); self->d_func()->aboutToQuitEmitted = true; sendPostedEvents(0, QEvent::DeferredDelete); } return returnCode; } ``` As far as I can tell, it's a small wrapper around `QEventLoop::exec` which also: * Sets some variables regarding the current status * Emits an `aboutToQuit` signal right before the function returns (which is the root cause of @denisri's problem in #2080). Historically, our Qt event loop is a python implementation of the (win 32) input hook supplied with the PyQt4 source (see qtcore_input_hook` in `python-qt4/sip/QtCore/qcoreapplication.sip`), which more or less dates to a [mailing list post](http://www.riverbankcomputing.com/pipermail/pyqt/2007-July/016512.html) from July 2007.

File last commit:

r3304:3cc304dd
r9834:71196839
Show More
util.py
106 lines | 3.9 KiB | text/x-python | PythonLexer
""" Defines miscellaneous Qt-related helper classes and functions.
"""
# Standard library imports.
import inspect
# System library imports.
from IPython.external.qt import QtCore, QtGui
# IPython imports.
from IPython.utils.traitlets import HasTraits, TraitType
#-----------------------------------------------------------------------------
# Metaclasses
#-----------------------------------------------------------------------------
MetaHasTraits = type(HasTraits)
MetaQObject = type(QtCore.QObject)
class MetaQObjectHasTraits(MetaQObject, MetaHasTraits):
""" A metaclass that inherits from the metaclasses of HasTraits and QObject.
Using this metaclass allows a class to inherit from both HasTraits and
QObject. Using SuperQObject instead of QObject is highly recommended. See
QtKernelManager for an example.
"""
def __new__(mcls, name, bases, classdict):
# FIXME: this duplicates the code from MetaHasTraits.
# I don't think a super() call will help me here.
for k,v in classdict.iteritems():
if isinstance(v, TraitType):
v.name = k
elif inspect.isclass(v):
if issubclass(v, TraitType):
vinst = v()
vinst.name = k
classdict[k] = vinst
cls = MetaQObject.__new__(mcls, name, bases, classdict)
return cls
def __init__(mcls, name, bases, classdict):
# Note: super() did not work, so we explicitly call these.
MetaQObject.__init__(mcls, name, bases, classdict)
MetaHasTraits.__init__(mcls, name, bases, classdict)
#-----------------------------------------------------------------------------
# Classes
#-----------------------------------------------------------------------------
class SuperQObject(QtCore.QObject):
""" Permits the use of super() in class hierarchies that contain QObject.
Unlike QObject, SuperQObject does not accept a QObject parent. If it did,
super could not be emulated properly (all other classes in the heierarchy
would have to accept the parent argument--they don't, of course, because
they don't inherit QObject.)
This class is primarily useful for attaching signals to existing non-Qt
classes. See QtKernelManager for an example.
"""
def __new__(cls, *args, **kw):
# We initialize QObject as early as possible. Without this, Qt complains
# if SuperQObject is not the first class in the super class list.
inst = QtCore.QObject.__new__(cls)
QtCore.QObject.__init__(inst)
return inst
def __init__(self, *args, **kw):
# Emulate super by calling the next method in the MRO, if there is one.
mro = self.__class__.mro()
for qt_class in QtCore.QObject.mro():
mro.remove(qt_class)
next_index = mro.index(SuperQObject) + 1
if next_index < len(mro):
mro[next_index].__init__(self, *args, **kw)
#-----------------------------------------------------------------------------
# Functions
#-----------------------------------------------------------------------------
def get_font(family, fallback=None):
"""Return a font of the requested family, using fallback as alternative.
If a fallback is provided, it is used in case the requested family isn't
found. If no fallback is given, no alternative is chosen and Qt's internal
algorithms may automatically choose a fallback font.
Parameters
----------
family : str
A font name.
fallback : str
A font name.
Returns
-------
font : QFont object
"""
font = QtGui.QFont(family)
# Check whether we got what we wanted using QFontInfo, since exactMatch()
# is overly strict and returns false in too many cases.
font_info = QtGui.QFontInfo(font)
if fallback is not None and font_info.family() != family:
font = QtGui.QFont(fallback)
return font