summaryrefslogtreecommitdiffstats
path: root/src/corelib
diff options
context:
space:
mode:
authorTor Arne Vestbø <tor.arne.vestbo@digia.com>2013-09-26 12:14:32 +0200
committerThe Qt Project <gerrit-noreply@qt-project.org>2013-09-30 16:32:29 +0200
commit999e5162ec3e86c9cb84c3ec95dfd0ba4b21277f (patch)
tree9da323a744addd7833335dd9e8de9a6eb7594f0d /src/corelib
parenta2bf063dd4942a95ffe971aed925afd4ad111ba6 (diff)
QPA: Fix semantics of GUI event dispatcher ownership in platform plugins
The QPlatformIntegration::guiThreadEventDispatcher() function acted as an accessor to event dispatchers created in the constructor of each platform plugin, but the logic and semantics of event-dispatcher handling in Qt itself (QCoreApplication/QGuiApplication) still assumed both ownership and control over the event dispatcher, such as when to create one, which one to create, and when to delete it. This conflicted with the explicit calls in the platform plugins to QGuiApplication::setEventDispatcher(), as well as left a possibility that the event-dispatcher created by the platform plugin would never be deleted, as none of the platform plugins actually took full ownership of the dispatcher and deleted it in its destructor. The integration function has now been renamed back to its old name, createEventDispatcher(), and acts as a factory function, leaving the logic and lifetime of event dispatcher to QtCoreApplication. The only platform left with creating the event-dispatcher in the constructor is QNX, where other parts of the platform relies on having an event-dispatcher before their initialization. We then need to manually take care of the ownership transfer, so that the event-dispatcher is still destroyed at some point. Change-Id: I113db97d2545ebda39ebdefa865e488d2ce9368b Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com> Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Diffstat (limited to 'src/corelib')
0 files changed, 0 insertions, 0 deletions