diff options
author | Tor Arne Vestbø <tor.arne.vestbo@digia.com> | 2013-09-26 12:14:32 +0200 |
---|---|---|
committer | The Qt Project <gerrit-noreply@qt-project.org> | 2013-09-30 16:32:29 +0200 |
commit | 999e5162ec3e86c9cb84c3ec95dfd0ba4b21277f (patch) | |
tree | 9da323a744addd7833335dd9e8de9a6eb7594f0d /dist/changes-1.39-19980506 | |
parent | a2bf063dd4942a95ffe971aed925afd4ad111ba6 (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 'dist/changes-1.39-19980506')
0 files changed, 0 insertions, 0 deletions