[Development] Qt 5.6: QWindowSystemInterface and event acceptance state

Sorvig Morten Morten.Sorvig at theqtcompany.com
Thu Sep 3 17:37:42 CEST 2015


Hi,

QWindowSystemInterface has recently gained the ability to return the “accepted" status of events, that is whether Qt used the event or not. The intended use case is Qt-as-a-plugin type scenarios, where we would like to propagate unhandled events back to the host.

The top level visible API change is that the handle*Event() functions may now return a bool instead of void, indicating if the event was accepted:

	static bool handleKeyEvent(..)

The catch here is that Qt must process the event before returning, which is incompatible with the current default QWindowSystemInterface queueing behavior. There are two ways to ensuring immediate processing:

1) Enable synchronous mode, which disables the event queue. The intention of this API is that platform plugins can opt-in at startup.
	QWindowSystemInterface::setSynchronousMode(true)

2) Flush the QWindowSystemInterface queue:
	bool accepted = QWindowSystemInterface::flushWindowSystemEvents()
(the accepted state returned is the state of the last event on the queue.)

Running Qt on a separate thread (like on Android) is supported. If none of these options are used then the value returned by the handle* functions is not meaningful.

The TODO list:
* Make more events return the accepted state. In fact, handleKeyEvent() is the only one that does this now. This mostly involves making sure the acceptance status is properly propagated from event processing higher in the stack.

* Unify the event implementation. Make tryHandleShortcutEvent() use this implementation instead of calling QGuiApplicationPrivate directly.

If there are any questions, feel free to ask here or contact me directly.

Morten





More information about the Development mailing list