Paul Olav Tvete

Remodelling the Lighthouse

Published Tuesday April 6th, 2010
7 Comments on Remodelling the Lighthouse
Posted in Lighthouse, Qt

We’ve moved!

First of all, before talking about our new plans, a belated announcement: We have moved lighthouse development from the lighthouse branch to the 4.7 branch in the same repository. (See, we didn’t stop working on it after all.)
Note: “4.7” just means that we are now doing Lighthouse on top of the Qt 4.7 codeline. It does not mean that Lighthouse is, could be or will be released as part of Qt 4.7.

Some TLC required

Ruined lighthouse by ibbertelsen  on Flickr
Ruined lighthouse by ibbertelsen on Flickr

No, it’s not that bad πŸ™‚ , but the original Lighthouse prototype was all about getting something useful with as little work as possible. This meant abusing some of the internal classes such as QGraphicsSystem and QWindowSurface by adding new virtual functions that were only available in Lighthouse. Most of those functions didn’t really belong where we put them: it was just that those classes were already there.

We have been thinking about this for a while, and the first step was taken back in February when Jeremy created the QWindowSystemInterface class that removed the dependency on QApplicationPrivate (which really isn’t a class you want to rely on in an API). Now we are working on the next step.

What are we doing?

We are still thinking out loud, and looking for the very best way to express the API, but we have a sense of direction, and we have already pushed some changes to repository. What we have done so far is getting rid of QGraphicsSystem. Since we’re now doing so much more than replacing the paint engine and pixmap backend, we needed a totally new class. The new name is:

QPlatformIntegration

(It still has the same virtual functions, so it’s not that hard to port old plugins to the new API.) We also changed the other classes that had “QGraphicsSystem” in the name, and we moved the plugins from the graphicssystem/ directory to the new platforms/ directory. Finally we get rid of the confusion between the graphicssystem plugins for the other Qt ports and the Lighthouse plugins. A summary of the changes:

  • QGraphicsSystem is replaced by QPlatformIntegration.
  • QGraphicsSystemPlugin is renamed to QPlatformIntegrationPlugin
  • QGraphicsSystemScreen is renamed to QPlatformScreen (since QScreen was already taken).
  • The command line argument -graphicssystem is replaced by -platform for Lighthouse.
  • Lighthouse now uses plugins/platform/ instead of plugins/graphicssystem

There’s actually one more class to be renamed: QGraphicsSystemCursor is looking pretty lonely by now. It will get a shiny new name fairly soon. Also, not all the plugins are updated yet; please be patient while we are porting the remaining plugins to the new API.

So, what more do we have to do? The next class that needs overhauling is:

QWindowSurface

The purpose of the QWindowSurface class is to abstract the drawing area of a window, at least that was the purpose before it got co-opted by the Lighthouse bunch. Making it represent the actual window as well is such a natural step to take, isn’t it? After all, they are just the same size and everything… There are at least two reasons why this turns out to be a bad idea:

One: if the window is resized, the surface needs to be resized, but if it’s the same class, the window will be resized again… Let’s hope the process converges eventually.

Two: Hypothetically, let “X” be a windowing system and say we want to have two different Lighthouse plugins, one that uses the raster paint engine, and one that uses OpenGL. In this case we will have to add the code that creates and manipulates X windows to both the windowsurface classes. If there was a class that only encapsulated the window, we could reuse that class in both plugins.

Therefore we want to keep QWindowSurface as a drawing-surface-only class, and move the other functionality over into a new class. The name of this new class is probably going to be QPlatformWindow. (We were thinking of just calling it QWindow, but that name may be useful for something else, and we don’t want to be selfish.)

What’s in a name?

While we are talking about names… There’s one name left that we need to replace before Lighthouse can be taken seriously and become a real part of the Qt family (which is not going to happen for 4.7 etc. etc. and so on). That name is Lighthouse itself, or the various incarnations of “lite”, to be precise. (“Lighthouse” is still a perfectly fine project name, and I’ll invite anyone who disagrees to step outside for a moment.) It turns up in least three different ways:

  • configure -embedded-lite ...
  • #ifdef Q_WS_LITE
  • qwidget_lite.cpp

If you have a great idea for a name, or indeed if you have opinions on any of the topics in this post, please share it in the comments section. Nothing is written in stone yet, and we’ll be happy to change any of it if we see a better idea.

Do you like this? Share it
Share on LinkedInGoogle+Share on FacebookTweet about this on Twitter

Posted in Lighthouse, Qt

7 comments

detro says:

What is the relationship between Lighthouse project and the Harmattan-all-Qt-based UI?
Is there some sort of learning-and-generalizing process going on?

If yes, Qt gets even MORE promising.

scorp1us says:

I am not seeing the difference (and this is an invitation to expound) Between QWidget and QPaint[er|Device|Engine] working together vs QPlatform* and QWindowService?

I would also wonder if QPlatform* also provided sound and input surfaces?

BeGo says:

Err, QLighthouse? For same reason, QPhonon?

TomCooksey says:

There is no relationship between Lighthouse and any Nokia platform whatsoever. Lighthouse is about helping embedded users customize Qt to easily run on their platforms, from dumb software framebuffers to fully fledged accelerated window systems.

Cheung says:

Since window management for lighthouse is done through plugins, I am wondering if it is possible to have a QWS plugin for lighthouse. I think QWS is a competent window system and it could serve as a default implementation for those who just need a generic window system.

Yes, in theory it would be possible to have a QWS plugin for Lighthouse. However, there are a number of design problems with QWS which makes this hard to do. (Mainly, poor encapsulation and separation of functionality.) It would probably be easier to take the good ideas from QWS (and possibly some of the code) and write a new, refactored window system.

jolind says:

There is now a branch in the lighthouse repository which is called platform_window. It contains the new experimental api for dividing QWindowSurface into two classes: QWindowSurface and QPlatformWindow. I have also ported the directfb plugin and the minimal plugin. Let us know what you think πŸ™‚ We will integrate the branch back once we have ported all the plugins and we are reasonably happy about the api.

Commenting closed.

Get started today with Qt Download now