Lighthouse is the Window System Agnostic port of QtGui. What that means is that QtGui doesn't know what windowing system it runs on, but pushes that logic into plugins.
A missing feature of Lighthouse up until now was that we didn't provide a multi-process solutions where you had Qt running on both the server side and the client side (like we had in QWS). You could write such a thing yourself, of course: Marius designed a protocol when he was creating his windowing system for his DevDays presentation. However, Paul and I both agreed on that we didn't want to create or maintain a protocol. One of the lessons from QWS is that making a multiprocess Window System protocol is difficult. QWS didn't really have a formal protocol, but rather something that just happened. This also resulted in the QWS server and client being very closely tied.
It would be nice if someone out there was just making a protocol that we could use. It turns out that the Wayland project is just that! Its a specification for a multiprocess windowing system. The Wayland client and server libraries gives means for communicating between server and client, but it does not interfere with what is being drawn, or how it is being composited. The server in Wayland is a compositing window manager, or "compositor" for short. For a deeper insight into Wayland, check out their homepage at: http://wayland.freedesktop.org/
For the last couple of months, Paul, Samuel and I have been getting our hands dirty with Wayland. What became apparent to us quite quickly is that there is not going to be one compositor to rule them all! An embedded device with a small screen has very different requirements from the Linux desktop. However, we would like many of them to be Qt compositors. We have therefore created a new labs project called Qt-Compositor. The goal of the project is to work as a tool box which is being used as a base layer for other people when they are going to write their own custom Wayland compositors.
Here is a simple diagram that I made which tries to show the intended architecture. The lighthouse plugin which runs on the screen will control mode-setting etc. The display information is available in the Qt-Compositor and Custom Compositor levels through Qt apis and Lighthouse apis.
Qt-Compositor abstracts away all communication needed by a Wayland compositor. Hence the primary task for someone who implements a custom compositor is how the surfaces will be drawn.
On the client side, the display information is sent over the protocol, and is available to all clients through the usual Qt-APIs.
What I think is exciting about this is that this setup is that a compositor can be made with utilizing any painting technology which is in Qt!
- If you want to compose them using QPainter on a QWidget: "SURE! why not. knock yourself out:)"
- If you want to compose them using QGraphicsView: "Hey! whats that scrollarea doing there:)
- If you want to compose surfaces using the up and coming Qt - Quick scene graph project: "oooh, that is interesting!"
A few days ago, Samuel made this super cool example compositor using qml scene graph. Its not a full featured compositor, but it shows some pretty cool features, like how to integrate Qt-Compositor with qml and how to easily write shaders for your surfaces.
