sabato 18 luglio 2015

How to make your Qt application icon appear on Wayland task managers

Several months ago I was redesigning the Hawaii launcher.

Now Green Island offers a class called ApplicationManager that emits signals when an application is registered or unregister (that is when a window of a certain class first appears or when the last one is closed).  This class is also exposed by a Wayland protocol for shells that are running in another process.

Soon I noticed that for some applications the launcher panel didn't show an icon and I realized there was something wrong with the app_id (also known as the class in wl_shell_surface).

The class name identifies the general class of applications and can be used by a task manager to know which desktop entry contains application information.

Unfortunately this is not as easy as it sounds because there is no way to tell that automatically.
So back in the day I had to set the class name to the executable name as you can see here.
This approach worked almost always because desktop entries were usually named after the executable.

However things changed recently, as a matter of fact desktop file names now follow the reverse DNS convention while executables keep being called like before.

This is now achieved by QtWayland with this commit reversing the QCoreApplication::organizationDomain property and appending the executable name. If the property is not set, QtWayland falls back to the old behavior.

The patch is available on Qt 5.4.2 and 5.5.0.

TL;DR: Rename your desktop files using the reverse DNS convention and set the organizationDomain properly.

QtAccountsService 0.6.0

We are proud to announce a new QtAccountsService release.
QtAccountsService is a Qt-style API for the AccountsService D-Bus service available for both C++ and QML.
Highlights of this release:
  • Use extra-cmake-modules
  • Use standard installation directories
  • Use new CMake macros to generate camel case headers
  • Link to Qt5 targets rather than using the old qt5_use_modules macro
  • Implemented UserAccount::setPassword
  • Export UsersModel to QML
  • Add a couple of small examples for C++ and QML

domenica 22 febbraio 2015

What's coming to Green Island: part 2

In the previous installment I forgot to post a screenshot of multiple output windows.

Here it is:

The first big chunk of code for multiple output support was recently merged into the qtwayland dev branch, but there is one more patch that is under review now.

Now I'm gonna talk about the recent development on Green Island.


Green Island now has:
  • a library that people can use to make their compositors reusing Green Island bits;
  • an executable named "greenisland" that links to the library and loads a separate QML based home screen;
  • an executable named "greenisland-launcher" that helps you run the compositor in several different environments;
  • a QML plugin that provides additional components such as the SurfaceRenderer for QML based home screens;


Green Island can run on a number of different setups: X11, Wayland, Raspberry Pi, KMS, you name it.

There is now a launcher that detects where it is running, sets environment variables and runs the actual compositor accordingly.


It's now possible to write custom home screens with QML.
The format is very simple but it might change slightly until the next iteration is released:
  • the home screen is a directory containing QML files and it's placed under $XDG_DATA_DIRS/greenisland (for example /usr/share/greenisland/org.vendor.coolhomescreen/)
  • the directory has a file called Compositor.qml and this is where you connect to the compositor and get events such as when a window is mapped or unmapped and create a QML window representation


Green Island supports the old wl-shell protocol as well as the new xdg-shell protocol that is now required for weston and Gtk+ clients.

Qt clients can also use xdg-shell but it's not the default, users need to set an environment variable to enable it.

For both protocols Green Island has its implementation which is independent from the one that comes from QtCompositor.

This allows me more freedom and frees me from the qtwayland release cycle.

venerdì 3 ottobre 2014

Maui using KDE Frameworks 5

In the past months cooperation has increased between Maui, KDE and LXDE developers, not only regarding libraries, but also key components such as SDDM (which has become the new standard for Qt based login managers) or Calamares, a new unified installer framework based on Qt.

In the meantime, KDE also released their long awaited effort named KDE Frameworks 5.
Frameworks 5 is a comprehensive set of technologies for the Qt ecosystem.

Its initial KDE libraries were modularized to be a set of “frameworks” instead of a single “blob”, making parts or the whole stack easily available for other desktop environments to make use of, therefore benefiting projects from the experience and dedication of the many KDE contributors over the years.

As a result of these latest developments, Maui has decided to start using KDE Frameworks as its underlying stack and become a member of the cooperative and open family that is KDE and Qt.

Along with the Qt open governance, developers of the whole ecosystem can now co-operate even more closely together and make better software.

Maui is now able to focus completely on the user experience of specifically building a lightweight and easy-to-use shell by empowering Frameworks and other great Qt technologies.

A lot of work has gone into that direction lately, advancing the Maui operating system.
We now have a repository based on Mer package sources and use the OBS infrastructure to enable collaboration and an easier workflow.
Mer is also part of the ecosystem built around Qt. Bearing that in mind and considering the outstanding work done by its developers, Mer is the right candidate for us.

To give users a first impression of these efforts, we decided to release an early alpha version (0.5.1) as installable ISO for 32-bit and 64-bit PCs.

lunedì 15 settembre 2014

What's coming to Green Island: part 1

I want to share with you some of the progress I recently made.
This is not all, more will come in another post.

Multi output support: part 1

Green Island now supports multiple outputs.

QtCompositor only support one output so in order to do this I did a little abstraction to enumarate outputs and played with QML to show them in the compositor window.

How does it work?

It's pretty simple: it has a ScreenModel that provides data such as name, primary boolean flag and geometry. The main QML file has a repeater using this model to create an OutputView for each output.

Every OutputView has layers to stack different kind of windows (panels, lock screen, workspaces), one of the layers is HotCorners which contains 8 hot corners.

During test and development one often need to fake outputs to test several different configurations without having real monitors, but this requires a dedicated backend and a configuration format.

So ScreenModel has its own backend code, one of the backends is based on QScreen and the other is for fake outputs.

Studying the problem and doing some prototype made me realize that QScreen has a very limited API (for example it doesn't detect when the primary output changes) and that this matter was already implemented with libkscreen.

It happens to be a framework that doesn't pull in undesired dependencies, so now Green Island is using it and I have to say it saved me a lot of work.

In the video below you can see a Green Island window with two 1024x768 outputs side by side, at some point the first one (which is also primary) is removed and all the windows are migrated to the other output that is now the new primary output.

Multi output support: part 2

A single big fat window for all the outputs is not such a great idea, it was good enough to continue the development keeping multiple outputs in mind but it's not the solution in the long run.

Such a solution may hit hardware limits pretty, plus outputs can have a different refresh rate so they really should not be done this way.

QtCompositor handles only one window so I patched it to be aware of multiple outputs with one window for each of them.
The patch targets the dev branch and at the time of this writing is in the review queue.

All the QML code was reused except for the Repeater and the logic to move windows when an output goes away was moved to C++.
This means that almost none of the code previously wrote was removed.

The hard part came when I needed to figure out how to show the same surface on multiple output windows.

Considering that QQuickItems cannot be shared between multiple windows I had to create a view for each output.

When a shell surface is created for a surface, the compositor creates a view that inherits from QQuickItem, the output is assigned based on the mouse pointer coordinates. No other view is created at this time because the position is calculated to be within output bounds considering the surface size.

More views are created on demand when the surface is mapped.

As windows are moved all views are moved accordingly, global coordinates are mapped to the output coordinates so that windows are shown only where they are meant to be.

Unresponsive applications

Wayland offers a ping/pong API that compositors use to know whether a surface is responsive or not, even with CSD (in the past there was some concern about this).

When a window is clicked, Green Island ping the surface and if it doesn't reply with a pong within 200ms it marks it as unresponsive and apply a colorize effect, draw some explanatory text, and intercepts mouse input. It also adds a couple of push buttons, one to wait for the application to become available again and the other to brutally murder the application.