Back in October of '09, Paul announced a windowing system plugin architecture for Qt. Actually, he introduced the lighthouse research project as a port to whatever architecture you may desire.
Subsequently, Morten and MBM posted about using lighthouse. Additionally, we've heard about some interest both inside and outside of Qt Developer Frameworks. That's fantastic. We're really excited about the potential of the project, and it's nice to hear that some of you are too.
While this is still very much in the research stage (Have I said that already?), it's high time we start nailing down some of the interfaces, and sharing our ideas about where this thing is going.
Press any key to continue:
Early on, lots of shortcuts were taken to get things going. One of these was user/window system input handling. Somehow those mouse movements, keyboard clicks, resize events and so on need to make it into Qt. The initial strategy placed methods in QApplicationPrivate, which processed the input events before delivering them with QApplication::sendSpontaneousEvent().
This strategy posed two important problems:
First, from a code organization perspective, asking developers to access methods in a class called *Private feels wrong. Looking at the corresponding header file, src/gui/kernel/qapplication_p.h, it says:
This file is not part of the Qt API. [...] This header file may change from version to version without notice, or even be removed.
And just in case you thought we weren't serious:
We mean it.
Problem #2 is a technical one, with its roots in the way that QEventLoop interacts with modal dialogs. In brief, the handler for an event doesn't return until any such dialogs (QComboBox, for example) have finished. This wreaks havoc with input systems that expect the event handler to return before dispatching any subsequent events. Try an early version of the vnc plugin with the groupbox example if you want to see what I mean. Click on the combo box and marvel at the lack of response from this point on.
We elected to address both problems by creating a new class, QWindowSystemInteraction. The intention is that this class is to provide interfaces for all of the events a window system might need to tell Qt about by way of the handle*Event() static methods. You should not instantiate or subclass QWindowSystemInteraction.
If you pulled from the gitorious repository recently, and your plugin doesn't compile because of missing QApplicationPrivate:: methods, it's worth checking to see if you need to make this change. The minimaldfb plugin is an excellent reference for the current state of development.
Within the implementation, events that might trigger a new event loop are queued, allowing the handler to return. Processing then waits until the next iteration of the event loop.
QWindowSystemInterface currently handles events related to:
A final caveat before I cut you loose to explore: This is still in development. Anything other than the handle*Event methods will likely disappear.