domenica 6 luglio 2014

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.

sabato 26 aprile 2014

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

domenica 16 febbraio 2014

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.

domenica 11 agosto 2013

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


DesktopUsage
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

mercoledì 12 giugno 2013

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.