The Qt® 4 Resource Center

Interview: Pier Luigi Fiorini

Pier Luigi Fiorini is the lead developer of Mockup. Mockup is an open source effort to create a modern desktop operating system. It is based on Linux 2.6 and supports native POSIX threading, hardware detection, automatic device creation and automatic network configuration.

The user interface, written using Qt 4, runs on Xorg, but will also support the framebuffer in future versions. The screenshots through out this article all shows Mockup in action. For the interested reader, there is alot more information available at

The Interview

Qt 4 RC: Hi Pier Luigi, please tell us a bit about yourself.

PLF: I'm a 22 years old guy that lives in Italy. I work as a software developer for YACME, an Italian company that work with Linux. We do consulting, training, system integration and software development. The programming language/tools I use for my job are Perl, C/C++, Python and Zope. I'm also a proud user of vim :)

Qt 4 RC: I understand that your project "mockup" uses Qt 4. Could you begin by telling us about what mockup is and what you want to achieve.

PLF: Mockup is a desktop operating system, based on GNU/Linux. We really love the new 2.6 kernel because it helps people that wants, like us, use the penguin on the desktop. The main problem here is that a lot of people think that Linux is ready for the desktop. Look at MacOS (both Classic and X) and compare it to Fedora, Novell Desktop or Ubuntu. These three distribution cannot win the comparison, because they are not the desktop that's in our mind (and probably it's neither the desktop that the Apple guys mean). We're using Qt4 because it's a great, multi platform toolkit. Both GNOME and KDE are not good desktop environments in our humble opinion. They are bloated, slow and not usable. Also, the so called desktop Linux distributions are not really targeted to desktop. Why a Linux distro ships with a lot of CD-ROMs full of software that won't be used by a lot of people? Why waste time, space and CPU for tons of console-based editors? Just choose one and provide it to your user. This is the philosophy behind Mockup.

At the moment Mockup's desktop environment needs X11 (although in the future will support DirectFB, when and if possible).

By creating our simple and fast desktop environment that's designed to run on our GNU/Linux foundation we'll be able to avoid some problems. Every GNU/Linux distro that wants to ship GNOME, KDE and whatever has some problems, it cannot provide stuff only for one environment because people that runs another environment will have problems. For example, we'll make a graphical login manager integrated with a sort of bootsplash that runs in user-space. We won't need to think a method to run gdm, kdm or xdm reading a parameter somewhere at some point of the boot procedure. We'll make a bootsplash in user-space that runs an X11 server that will be used by our graphical login manager. There never be a /etc/sysconfig/desktop file :)

The way we're working allows us to provide users a consistent desktop, one toolkit, one desktop.

Some people still think that the Mockup project is somewhat reinventing the wheel. This is not true because both GNOME and KDE don't fit our needs. They rely on X11 (while we are working keeping in mind that our desktop needs to run on another windowing system in the future) and they are not usable. GNOME tries to remove a lot of option from user's control, for example the window manager cannot be changed easily. This is good but why they let users choose what sound system GNOME has to use? We made our choice, it's ALSA and Jack. GNOME needs to run on other operating systems than Linux, probably they made the choice available for those running on platforms that can have multiple sound systems, but this is not good. A sound system for each platform should be selected by the GNOME team.

The Mockup project wants also to provide hardware detection (hotplug and coldplug), automatic device files creation and automatic network configuration. If your network device is automatically detected it will be also automatically configured (searching for a dhcp server, for example).

We want to achieve full integration and consistency between every application.

Qt 4 RC: So, you want to provide a consistent desktop with a consistent set of underlaying technologies. Tell me why you choose Qt?

PLF: The project started as BeFree, a rewrite of the BeOS API on FreeBSD and Linux. Then the specification of BeFree was improved but I had a lot of problems. It's not possible to create a project like BeFree the right way, at least not when a lot of people send you mails and tell you "I love your idea, keep up the good work" and nobody wants to contribute. People involved on writing BeOS API on Linux/*BSD never helped much and their project are stalled. I looked for a lot of alternatives and I rewrote some C/C++ code many times, it was BeOS inspired but it a nice class like QAction. I never given Qt a real chance because Qt 3 was not exciting. I choosen Qt 4 because it's thread safe, it supports vector graphics, nice classes, container classes are very helpful and signals/slots are very easy to use. Signals/slots are a step forward, BeOS had a lot of message passing but the Qt approach is much elegant. Qt 4 does run on Mac, Windows, X11 and Framebuffer. I don't care about Mac and Windows but my dream is a GUI that runs and DirectFB and, although an investigation is planned in the long term, Qt will make my work easier.

Qt 4 RC: Lets stay with signals and slots for a while. I've noticed that you use DBUS. This allows you to connect signals and slots across application boundaries. Is this something that you find useful? Perhaps something that you feel aught to be a part of Qt it-self?

PLF: Yes it's really useful. D-BUS is a cross desktop IPC system and it should be widely adopted, its Qt4 support is really exciting, but it shouldn't be part of Qt. Qt is a cross platform toolkit, it can't provide something that works on a platform and doesn't work on another one. QtDBUS will be probably included in D-BUS, so you'll be able to build Qt4 bindings.

I wrote a simple implementation of a user-space virtual file system. It's a DBus server, the client is a class in our API that can do asynchronous operations like listFolder(), readDocument(), ... The client invokes methods of org.mockup.vfsdaemon which is running on the DBus session bus, when the client invokes a method it pass some information to the server (which is at least a QUrl). The server has a hash that maps protocols to BProtocol pointers, only one protocol is always available: it's the file protocol to access the local file system (in fact I think that probably I should do a client side implementation for the local file system, just to speed it up a bit). When the client calls a method, the server creates a BProtocolOperation pointer and spawns a thread passing a pointer to the protocol and the operation to it. Protocols emit signals like started(), finished(), folderContentsChanged() and the thread handles them with its slots where it sends signals to the client. I know this seems a bit slow but it's easier and less error prone than some classes in the public and private APIs, this way developers will only see BUrlOperation which is the client that communicates with the server. QDBus converts QVariant to DBus types but unfortunately it doesn't support custom types yet, so I cannot send something like QUrlInfo - we'll se how to address this problem.

Qt 4 RC: If we delve into the new parts of Qt 4. Have you looked into Interview, the model-view-framework f�t?

PLF: Yes, Interview is interesting. It's a nice separation of the model from the view. This was not possible with Qt3. Just define your delegate and link a view to your model. It's even possible to define an editor, read/write views can activate it, this feature is useful for applications like the Designer's properties editor. TrollTech, as always give us a lot of examples to learn how Interview and other new things work.

Qt 4 RC: I suppose that this comes in handy in all sorts of places. Do you have any particular situation where this framework has helped you in Mockup?

PLF: Yes, it's pretty useful these days that I'm completing my work on the file manager icon view. Now that I have a decent VFS I must implement a new BDirModel. This class is actually inherited from QDirModel just to use my BFileIconProvider that uses the class BIconTheme (that's used to read's Icon Theme standard-compliant themes). My goal is to improve BDirModel, it should now be inherited to Qt's model class and should also take care of MIME handling. The Interview framework will help me writing the background preferences applet, that will show backgrounds in a list view.

Qt 4 RC: What about the other big change in Qt 4 - Arthur. There where problems with Qt 3's drawing engine that got apparent as it aged. Do you feel that Arthur is flexible enough to be useful in the next couple of years?

PLF: I haven't used Arthur 100%, I'm developing the theme for the GUI you'll find in Mockup 1.0 and I think a more complex theme will be used for Mockup 2.0. What I'm doing now is to get an API that will be easily improved for the second major release. I tried the theme with antialiasing but the quality is not good, antialiasing is better for a neat theme (like MacOS Aqua). One of my dreams is a resizable GUI, and it seems that these things are possible with Arthur because it lets you draw vector graphics.

Qt 4 RC: Even as you only have touched Arthur, what are your opinions about it? For example, do you think that the better support for alternate backends will be utilized?

PLF: I don't know if I'll use the support for alternate backends in Mockup but now it's possible to open a QPainter on a QGLWidget as if it's a normal QWidget with a huge benefit because we can use OpenGL for most of the drawing operations.

This is the way to go, for example people are working on Xgl to move rendering of windows contents to OpenGL. As far as I understand, with the new QPainter/QPaintDevice you can even use Cairo, although it doesn't make sense. It doesn't make sense because QPainter provedes what Cairo has, with a nice Qt-based API :)

Unfortunately, although QPainter supports OpenGL, it's still a pain to get accelerated OpenGL working on Linux with ATI and Nvidia. I own a Radeon 9000 and a GeForce MX 400 so I've tried both proprietary drivers. The ATI one is slowly developed while Nvidia pays much attention to their Linux driver but I still can't get a PPC driver and on x86 I have problems on Debian/Ubuntu with XFree 4.3 and XOrg 6.8.2 (I can only see the Nvidia logo and nothing else, it covers the entire screen and if I disable the logo I will see a black window on the desktop).

That said, I think QPainter rocks, it's a nice abstraction that provides both pixel and vector based drawing and I think that one day someone will use even the OpenGL, other backends are already in use (X11/XRender and framebuffer for example).

What I want to see in the future is a scalable GUI, just like the "em" unit in CSSs. Defined a base unit, it would be cool to resize the GUI with multiple of that unit.

Qt 4 RC: Dealing with Qt 4 in general, do you think that it is a quantum leap and will make a change, or is it just another version of a great toolkit?

PLF: It's not another version, Qt4 is made of great changes to Qt3. With Qt4, it's time to write new code (as I'm doing for Mockup) or rewrite messed up code (as KDE developers will do, they are good programmers but I doubt their code is perfect).

The first advantage is Toolip. Qt3 had QTL containers like QValueList but now you have new iterators (with a nice syntax inspired by Java, STL-compatible iterators are available too), containers are optimized and when empty they don't allocate memory (they only requires the same space as a pointer) and even if they are implicitly shared they can safely be copied across threads. Interview lets you use Model-View-Controller design pattern, with the new QPainter, enhanced thread support with signal-slot connections across threads and per-thread loops and the resource system the porting is a thing a lot of Qt3 users must think.

In the early days of Mockup I used Qt3, just because Qt4 wasn't even mature for a developer, but now I'm really happy of Qt4 beta2.

Click the image for more screenshots.

Qt 4 RC: So, Qt 4 is simply a better Qt, and Mockup will be a better UI. For those who are intersted in Mockup and Qt 4 coding, is there an easy to way to get hacking?

PLF: To learn Qt 4 coding there's a great way, point your browser to either or /opt/qt4/doc/html/index.html (if you installed Qt in /opt/qt4) and read some articles (

Writing Mockup applications is just like writing Qt4 applications. I am working on some libraries to provide support classes and new widgets that are integrated with the desktop environment (for example the class for the file manager view, file chooser dialog, support, ...). Actually you have to download the code and read some headers, but a lot of classes already have Doxygen comments so when the API will be stable enough, I'll release the documentation.

The HIG we are working on will be another great piece of documentation, people have to understand that Mockup applications won't be hard to write than plain Qt4 apps, but there are some guidelines and specifications to take care of. Third party applications (applications not provided by Mockup) must be coherent with the whole desktop, unless you want to reproduce the "Linux desktop" pain :)

Qt 4 RC: Thanks alot for your time! And good luck with the development of Mockup!

Since the time of the interview Qt 4.0.0 and 4.0.1 has been released. The Mockup project has also evolved, so make sure to visit them at to catch up with the latest development.