SDDM v0.18.1

We are happy to release a new SDDM version.

SDDM is a Qt based graphical login manager developed in a collaborative fashion by people from Liri, KDE and LXQt.

This time around we made a point release with the following hot fix:

Use C++ scoping for handling buffer deletion - link
SDDM is developed by volunteers, please consider donating money that can be used to support the features that you most desire.

We now have a Bountysource page and I hope that we can get more developers to help us, as we are sometimes struggling to keep a consistent pace with the development.  Having a full time developer, would even be better, but we can start with bounties and see what happens.

Download the source code here.

SDDM v0.17.0

We are happy to release a new SDDM with a few improvements.

SDDM is a Qt based graphical login manager developed in a collaborative fashion by people from Liri, KDE and LXQt.

This new version include the following changes:

* Added possibility to change border width of ComboBox widget.
* Added missing utmp/wtmp/btmp handling.
* Make greeter see icons set by AccountsServices.
* Fix sddm.conf man page syntax error and update.
* Fix ComboBox widget.
* Fix connection of PropertiesChanged event for LogindSeat.
* Avoid race conditions with Xsetup.
* Update de translation.
* Update lt translation.
* Update zh_TW translation.
* Adjust order of components in the default PATH.
* Set default input method to qtvirtualkeyboard.

Download it here.

SDDM v0.16.0

SDDM is a Qt based Display Manager used by multiple desktops, such as Liri, KDE and LXQt. After a little more than one month since v0.15.0, I released SDDM v0.16.0 today. It contains a few bug fixes, translation updates and improvements to the configuration system. Read the release notes and download here.

Qt Virtual Keyboard support on Hawaii

Ever since Qt Virtual Keyboard was introduced a couple of years ago I desired to integrate it with Hawaii, especially considering the effort to make the whole workspace adapt to different devices started a while ago.

However Qt Virtual Keyboard was a value-add component for Qt Enterprise customers, until things changed recently.

As part of the recent licensing change announcement, Qt Virtual Keyboard is now available also with GPLv3 license for Open Source users in addition to commercial Qt licensees.

This move allowed me to finally integrate Qt Virtual Keyboard with Hawaii, which soon will also be available on SDDM.

Qt Virtual Keyboard will be included with Qt 5.7 but it's possible to build the sources from the git repository now, against Qt 5.6.

The virtual keyboard is an input method so activating it is as easy as setting an environment variable, as outlined in the deployment guide:

export QT_IM_MODULE=qtvirtualkeyboard

To make it easier and less error prone a setting for Hawaii has been added that you can enable from the keyboard settings.

On desktop systems the keyboard is resized so that it won't cover search and password text fields.

Obligatory screenshots below:

SDDM 0.12.0 released

We are proud to announce the immediate availability of SDDM 0.12.0.

This release features working Wayland sessions for the first time, but the greeter is still running on Xorg.

This means that you will be able to login into a Wayland desktop environment without problems however the greeter screen still depends on X11.

Work on the Wayland support for the greeter has already been started and will likely be available with the next release.

Highlights of this release:

• BACKWARDS-INCOMPATIBLE: SDDM now depends on Qt >= 5.3
• BACKWARDS-INCOMPATIBLE: Display setup script is now killed if it hasn't finished within 30 seconds
• LICENSING: The Maldives non-free background has been replaced by a CC-BY-SA alternative
• WAYLAND: Wayland sessions support
• CONFIG: New sddm.conf option `XephyrPath` (defaults to `/usr/bin/Xephyr`)
• CONFIG: new sddm.conf option `ServerArguments` (defaults to `-nolisten tcp`)
• CONFIG: new sddm.config option `DisplayStopCommand` (executes Xstop)
• THEMES: Assorted improvements to the default theme
• BUGFIX: Honor TryExec in Xsession desktop files
• BUGFIX: Fix session startup on zsh
• BUILD: Allow setting a custom `DBUS_CONFIG_FILENAME` at compile time
• BUILD: Allow `SYSTEMD_SYSTEM_UNIT_DIR` to be overridden at compile time
• BUILD: Allow `QT_IMPORTS_DIR` to be overridden at compile time
• BUILD: No longer hardcode min/max UIDs, allow setting `UID_MIN` and `UID_MAX` at compile time
• BUILD: Assorted FreeBSD fixes
• BUILD: Fix build warnings with Qt 5.5
• BUILD: Enable `QT_NO_CAST_FROM_ASCII`
• I18N: Added Arabic, contributed by Safa Alfulaij
• I18N: Added Hungarian, contributed by @mortein79
• I18N: Various i18n updates and improvements
• I18N: Full right-to-left languages support

More information can be found here.
Sources and SHA1 hashes follow:

• sddm-0.12.0.tar.gz (SHA1: 9d2b1f7ac3bbbf7c60555b3809179f5c95449e09)
• sddm-0.12.0.tar.xz (SHA1: 985aee2bbafd42969353786cc3dd63b2695cb848)

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

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.

Refactoring

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;

Launcher

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.

Plugins

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

xdg-shell

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.

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.

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.

Maui using Mer

Back in Sep 2012 I sent an email to the Qt Interest mailing list showing off Hawaii and what I was doing.

After that I've been contacted by a couple of people from the Mer Project that explained to me what Mer is and what advantages it offers.

After I recovered from the overwhelming quantity of information to process I found a very warm and enjouable community.

Mer didn't come at that time with x86_64 support which was and still is pretty important to me because the main focus is desktop and todays machines are likely to have 64-bit capable CPUs.

Another issue was packages that were not up to date. Hawaii requires the latest version of many packages (mainly systemd, wayland and Qt) and so I decided to keep using Yocto as a base system building components on top of it with mauibuild and postpone my decision.

Here we are now, I've been using and updating Mer for the past months, packaged a lot of stuff and worked on a few adaptations besides x86 and x86_64, mainly Raspberry Pi.

OBS is a very nice tool that does a lot for you like rebuilding dependencies when you update a package and with kickstart it's been quite easy to make images.

There's a new mauibuild work in progress version that builds images from kickstart files with mic.

mic, the image creator, has been extended with a few plugins for Maui that bring improved syslinux configuration, dracut support, plymouth and plymouth-lite detection, and UEFI support although this cannot be used until I packaged grub2 and all the signing stuff.

Now that OSTree is getting RPM support this migtht work out very well with my original idea of atomic upgrades.

Even if Mer now has x86_64 support there's a nasty bug preventing me from creating x86_64 images but I found a way to work around the issue, I will likely be able to build both 32-bit and 64-bit images soon.

2048 with QML

So apparently everyone's crazy about the 2048 game.
I'm probably the last guy on Earth that discovered it but I really enjoy it.

Since my phone doesn't have a data plan I decided to port the game to QML, so I can play it with my Jolla while commuting to work.

To kill two birds with one stone, I started writing a desktop friendly version for Hawaii but it can be used in any desktop environment and once touch support is added it will work on mobile too.

You can find the source code here.

The logic code has been ported straight from this version, which BTW seems the original implementation. It was the easiest part but I must admit that the graphical part didn't take more time thanks to QML.

Colors are from this version but I plan on letting the user change it.

The UI is fully scalable so here's how it is at startup:

but the grid and the text inside tiles is scaled (although calculation is a bit lame) with the window keeping its aspect ratio:

I did this a month ago and never had the time to polish it.

Off the top of my head there are a few important things left to do:

• Animations
• Palette loading

Updates and plans for the next Hawaii version

QtDay and FOSDEM are over and I finally took some time to update the plans for the next Hawaii version.

First things first. Next Hawaii iteration will be the 0.3.0 release.
At first I thought to do minor improvements in a 0.2.1 version and release shortly after 0.2.0 but then I decided to do more work.

Most of the stuff is already implemented at this point, but it needs further improvements.

So what should you expect for Hawaii 0.3.0?

Weston 1.4 is here now so the plugin was ported to the new version, some code refactoring is needed though to make the code more manageable.
The plugin will also support drop-down windows and a whitelist for trusted clients that need to access some Wayland interfaces (a possible usage is a screenshot application).

Shell is going to be improved with better multiple screen management, multiple panels (you can have one panel for each edge), configuration directly accessible from the panel, elements in panels can be reordered.

There was also a major refactoring, components such as dialogs, popups and overlays were moved to a plugin that can be used by external QML applications.

This was necessary in order to separate the PolicyKit agent and notifications daemon from the shell.
Other desktops (I'm thinking about LXQt here) can use these components more easily now if they wish.
Both are not launched by the shell automatically and currently there's no switch to turn them on and off but there are units for the systemd user session so you can manage them from the command line or with a graphical frontend. I can't exclude a service manager integrated in Hawaii in the future but there are no plans yet.

Compositor and deamons now notify systemd upon startup and as I mentioned above there is support for systemd user session however I'm having some problems running weston.

Screensavers. Yes it's a bit anachronistic but some people might enjoy it.
It's disabled by default and currently there is no switch to turn it on and off, later a preferences applet will be available.

As I showed during FOSDEM, now Hawaii can switch between different layouts on the fly.
This is one of the main goals of this project and goes by the name of convergence these days.
I will talk more about it in another post but the idea is to have a dedicated user interface for different devices and even react to things like input devices or screen resolution changing.

This work also make it easier to implement animated wallpapers because the shell is now much modular and can load different components.
Currently the background is implemented by a QML component that according to the settings draws a picture, a solid color or a gradient.
Animated wallpapers are just loadable QML components that does nice stuff such as animations, react to mouse click and tap to change the background and so on.
At this point it becomes clear that Hawaii needs a generic way to deal with this things, hence the standard background is going to be split in a wallpaper plugin, a solid color plugin and a gradient plugin and will be no more different than animated wallpapers.

Here you can see the task list.

Hawaii responsive user interface

This was written after FOSDEM but never had the time to finish it and do the video so with too many months of delay I've got some time in my hands to post about the Hawaii desktop environment responsive user interface.

Hawaii is currently focused on desktops and laptops but it's always been a goal to get ready for other devices as well supporting screens with different DPIs.

Why bother, can't we just do the same user interface and let the controls scale according to DPIs and expand contents to fit the screen size? No, we can't because there are differences between devices.

Desktops and laptops have a keyboard and most of the time a mouse and to complicate things even further they can also have a touchpad, for example I own an Apple Magic Trackpad.  Mobile devices, on the other hand, have touch input, no keyboard and higher DPIs.

The same user interface cannot be used for different devices, the user expects it to suit the device.

On a tablet the user expects to see an application at a time and use several gestures, there is also less screen space so you have to design interfaces with fewer things on screen.
The opposite is true on desktop where you can show multiple windows and some tiling feature is more than welcome and since the mouse is more precise you can put more controls on the screen.

Today there are some devices like the Yoga that can alternatively be turned into either a tablet or a laptop. The only problem is that it's not cheap, I will have to save money before buying one :)

That's why I prefer calling this responsive user interface rather than convergence.

Hawaii should react on events such as screen resolution change, mouse plugged in or touch input device plugged in and load the user interface that is willing to step in and show a user interface for the current setup.

To make development easier the switch happens reading settings with the QtConfiguration library that supports changes notifications. That's enough to simulate an event. In the future I plan to use Solid to determine what's the current setup like, but maybe QScreen and QTouchDevice will be sufficient.

Most things that a desktop environment need can be shared between shells, for example lock screen management, idle state management, notifications, power management and sounds are all features that need to be done once.

With Green Island, the QML compositor, one can also plug in different ways to manage windows and panels all with their Wayland protocol interface.

This is not all. Applications need to switch the user interface too, so I've been experimenting with QFileSelector and QQmlUrlInterceptor.

In the application demo I have used QQmlUrlInterceptor.
The application has a content directory with the QML code for the desktop with the following subdirectories that override files for specific profiles: +phone, +tablet, +touch

The +touch subdirectory contains code for all touch user interface, one example is the list view delegate, +phone and +tablet override the main view (the tablet version has a menu that can be pulled from the left with a gesture while the phone version has it always visible).

For demo purpose, the user has to pass all the relevant profiles to the application so for example if I want the tablet version both touch and tablet are passed as arguments.

Here's a little video showing the switch from a tablet UI to a desktop UI and different layouts for the same application.

As you can see the tablet user interface has two panels (launcher at the bottom edge and a smaller panel with indicators on top), it also have a desktop view with a search bar and application icons. Stacked below there's the background view.  The desktop user interface is the classic Hawaii shell that has a bottom panel with more elements.

Hawaii memory usage

Since Hawaii 0.2.0 is closer I wanted to collect some stats about its memory usage.

Measuring resources usage reliably is a bit hard, but it seems that KSysGuard provides detailed results and keep shared libraries into account.

While I'm here I will compare Hawaii with XFCE, although there's no much value in it due to the difference between the two stacks except for being aware of what another low footprint desktop is doing in its current form.

So, let's see how much memory does it take Hawaii, measuring a session with some applications open (System Preferences, Terminal, Eyesight, Swordfish and QupZilla and Communi) after using it for a while.

Currently Hawaii is using Weston although in the future it will use Green Island, a QtQuick compositor using the QtCompositor API.

As you can see from the screenshot below, there are two Weston processes running.

Weston processes

Details below:

weston process memory usage

weston-keyboard process memory usage

Total memory usage: 23.4 MB

Now let's see the desktop environment...

Hawaii Shell memory usage

dconf-service memory usage

dconf-service is included to match XFCE which has xfconfd.

Total memory usage: 64.47 MB

Compare now with a low footprint X11 desktop environment: XFCE.

In the X11 world we need two programs to cover the Weston features: the Xorg server and a window manager/compositor, XFCE uses xfwm4.

Total memory usage: 122.9 MB

From the features point of view we should compare Xorg + xfwm4 with weston (122.9 MB vs 9 MB) but I think this is due to the different architecture.

To be fair I'm measuring only XFCE components that has a Hawaii counterpart, so xfce4-power-manager is not included and judging by the package description xfconfd can be compared to dconf.

The panel-6-systray process is not included either, if it does what the name suggests then Hawaii can't match it because it doesn't support the System Tray Protocol.

xfsettingsd might be left out (although I'm not sure) because Hawaii doesn't have a daemon to propagate settings.  However Hawaii doesn't need it for settings such as icon theme, widgets style, fonts etc... they are managed by a platform theme plugin but other settings such as mouse cursor theme and size would need something to propagate those settings to Qt applications as well as non-Qt applications.

XFCE doesn't have a PolicyKit agent like Hawaii, or at least I couldn't find any.

xfce4-panel memory usage 

xfdesktop memory usage

xfce4-session

panel-2-actions memory usage 

xfconfd memory usage

xfsettingsd

xfce4-notifyd memory usage

Total memory usage: 31.22 MB

Desktop	Usage
Weston	9 MB
Hawaii (weston-keyboard + hawaii-desktop-shell + dconf)	14.4 + 63.7 + 0.773 = 78.83 MB
Total: 9 + 78.83 = 87.87 MB
Xorg and xfwm4	115.7 + 7.2 = 122.9 MB
XFCE (xfce4-panel + xfdesktop + xfce4-session + panel-2-actions + xfconfd + xfsettings + xfce4-notifyd)	9.8 + 6.5 + 4.2 + 2.8 + 0.721 + 2.9 + 4.3 = 31.22 MB
Total: 122.9 + 31.22 = 154.12 MB

EDIT: As requested in the comments I capture the output of free and memuse on my Archlinux system before running Hawaii from KMS (fullscreen 2560x1440) and from the Hawaii session.

Output of free after the system is started: https://gist.github.com/plfiorini/6326618
Output of memuse after the system is started: https://gist.github.com/plfiorini/6326621

Output of free running from Hawaii on KMS: https://gist.github.com/plfiorini/6326633
Output of memuse running from Hawaii on KMS: https://gist.github.com/plfiorini/6326628

Hawaii System Preferences, Part 2: How preflets are loaded

System Preferences can be extended with plugins.

Plugins inherit PreferencesModulePlugin and return a new PreferencesModule instance that has preflet information such as name, description, icon name, category, whether it requires administrative privileges (helpful for preflets that deal with system settings).

System Settings has a simple model that iterates over the plugins directory, load plugins with QPluginLoader and create module instances.

In the QtWidgets-based version, PreferencesModule inherited from QWidget, the preflet was then a widget that System Preferences added to a stacked widget. When the corresponding icon was clicked, the current index was changed showing the preflet's widget.

Since I'm rewriting everything in QML, PreferencesModule now inherits from QObject and has a new item() method that preflets implement returning a QQuickItem object created by loading the QML code embedded into the resources with QQmlComponent.

The loading mechanism is pretty much the same, the model exposes the QQuickItem with the item role, when the preflet icon is clicked the item is pushed to a StackView.

Hawaii System Preferences

With the imminent release of Qt 5.1, QML is going to be a serious tool for desktop applications development.

With QtQuick Layouts and QtQuick Controls we can finally create complex user interfaces and drop QtWidgets and that's exactly my goal for the Hawaii System Preferences applications.

This is how it looks like today:

System Preferences uses KDE's categorized view imported into Vibe, which is a nice view that allows you to categorize a list view and filter the results; in this case I filter the results by keyword to gray out and disable icons that don't meet the search criteria:

However, as you can see from the screenshots, there's an annoying bug that cuts the labels out.

Rewriting it with QML is easy, here's the code for the main window:

import QtQuick 2.1
import QtQuick.Controls 1.0
import QtQuick.Layouts 1.0
import Hawaii.SystemPreferences 0.1

ApplicationWindow {
    id: root
    title: qsTr("System Preferences")
    width: 640
    height: 640
    minimumWidth: 640
    minimumHeight: 640

    toolBar: ToolBar {
        id: mainToolBar
        width: parent.width

        RowLayout {
            anchors.fill: parent
            spacing: 10

            ToolButton {
                action: actionBack
            }

            Item {
                Layout.fillWidth: true
            }

            TextField {
                id: searchEntry
                placeholderText: qsTr("Keywords")

                Layout.alignment: Qt.AlignVCenter | Qt.AlignRight
            }
        }
    }

    Action {
        id: actionBack
        iconName: "view-grid-symbolic"
    }

    StackView {
        id: pageStack
        anchors.fill: parent

        initialItem: Item {
            width: parent.width
            height: parent.height

            ColumnLayout {
                anchors.fill: parent

                Repeater {
                    model: CategoriesModel {}

                    GroupBox {
                        title: label

                        Layout.fillWidth: true
                        Layout.fillHeight: true

                        ScrollView {
                            anchors.fill: parent

                            GridView {
                                id: gridView
                                model: PrefletsProxyModel {}
                                delegate: GridDelegate {
                                    width: gridView.cellWidth
                                }
                                clip: true
                                cellWidth: 100

                                Component.onCompleted: gridView.model.setFilterFixedString(name)
                            }
                        }
                    }
                }
            }
        }
    }
}

Unfortunately I couldn't find a replacement for the categorized view so I decided to repeat a scrollable grid view inside a group box for each category. Far from what I want but it seems the grid view doesn't have something like this, but there's time to improve System Preferences.

The grid delegate was easy to do:

import QtQuick 2.1
import QtQuick.Controls 1.0
import QtQuick.Layouts 1.0

ColumnLayout {
    Image {
        source: "image://desktoptheme/" + iconName
        sourceSize: Qt.size(48, 48)
        width: 48
        height: 48

        Layout.alignment: Qt.AlignCenter
    }

    Label {
        text: title
        horizontalAlignment: Qt.AlignHCenter
        wrapMode: Text.Wrap

        Layout.fillWidth: true
    }
}

And here's how it looks like:

Colors are from the standard Qt palette which will be replaced with some grayish palette for Hawaii soon.

Qt AccountsService

Recently I started working on a Qt 5 addon for AccountsService.

AccountsService is a D-Bus service for accessing the list of user accounts and information attached to those accounts, as its web site says.

You can learn more about it here.

Qt AccountsService Addon is basically a Qt-style API to use this D-Bus service and also offers a model that represents users, the API can also be used from QML.

You can check out the source code from here.

The code works, I'm already using it in several projects but there's no promise of API stability right now although I haven't made too much changes lately.

Hacking on documentation

Tonight is a pretty boring night, instead of coding for the Vision operating system I'm writing some documentation.

Writing documentation is always boring but sooner or later I must start doing it in order to be prepared for the first technology preview.

I also evaluated the CMS. After trying Drupal and WordPress the latter have been chosen, it also seems easier to integrate with Wikimedia with some sort of SSO.

So I'm writing some articles on the project's history and goals and I'm writing the structure for the HIG.

Maui

Some years ago I started several projects all based on the Linux kernel and GNU userland with the intent to create a better desktop user experience.
I was not satisfied by GNU/Linux distributions in the day by day use, my ideal system was BeOS which by that time was dead with Be, Inc the company behind it. An Open Source effort to recreate it, known as OpenBeOS (now Haiku), was started in 2001, but it certanly wasn't a viable option because it was in an embryonic state and what was missing from the original BeOS API was scheduled after R1 which as of today it's not reached yet!

BeOS shipped with a state of the art C++ API and a very elegant desktop with many features that later became standards like metadata and queries; it simply was everything Linux wasn't.

Basically I though GNU/Linux on desktop had the following major problems:

• No coherent API and design.
• Low propensity of developers of all desktop environments and toolkits towards a functional, uncomplicated and pleasant, out of the box experience.
• Several software to do the same thing, none of them complete.
• Inability to move to modern graphics architecture because of the dogma of X11 compatibility.

Haiku was progressing, and I kept thinking that it wouldn't go anywhere without a Linux kernel and its better hardware compatibility.  Although Haiku was still years away from completion, in 2003 I started porting its API to Linux.

I made two prototypes, the first was running on X11 with Cairo (which I believe was called Xr/Xc at that time) and the other more successful was based on DirectFB and had not display server (all client side). The Haiku API would have been a good start to implement what was missing from BeOS because of its age (layouts, notifications, standardized actions a-la QAction and many more) without waiting a lot of years.

At some point the enourmous amount of work needed to complete the project and the lack of interest from the potential users threw me into despair. We have to be honest here, BeOS zealots were not willing to use a Linux-based BeOS bastard (they did prefer to wait more that ten years for an early 2000 era operating system almost exactly the same as BeOS), at the same time Linux users was skeptical about it and I certanly did not help missing the second part of the "release early, release often" mantra.

With this project left behind be I decided to take another path: between 2004 and 2005 Qt 4 Technology Preview came out and it was amazing. Clean, complete, modular, supported the MVC pattern, multi-threading and OpenGL. In 2005, the Mockup project was started.
I didn't have much spare time to dedicate on the project, so in the end it was abandoned.

The years passed...

...and suddenly last year, browsing the web, I discovered a nice project: Wayland. Finally there's a viable option that can finally let X11 retire. I started writing some code for a file manager and a panel without the goal to restart the Mockup project.

I was just looking for a challenging pet project and I didn't want to publicly announce something.
Some more month passed, it's 2011 now and I feel it's time for me to write this blog entry because I'm proud of the code I wrote so far - in the last month I wrote a lot of code, my effort and committment is way more than my previous attempts.

So stay tuned to learn more about the Maui operating system.