Progressing towards Next

In the Plasma team, we’re working frantically towards the next release of the Plasma workspaces, code-named “Plasma Next”. With the architectural work well in place, we’ve been filling in missing bits and pieces in the past months, and are now really close to the intended feature set for the first stable release. A good time to give you an impression of what it’s looking like right now. Keep in mind that we’re talking Alpha software here, and that we still have almost three months to iron out problems. I’m sure you’ll be able to observe something broken, but also something new and shiny.

For the first stable release of Plasma Next, we decided to focus on core functionality. It’s impossible to get every single feature that’s available in our long-term support release KDE Plasma workspaces 4.11 into Plasma Next at once. We therefore decided to not spread ourselves too thin, and set aside some not-quite-core functionality for now. So we’re not aiming at complete feature parity yet, but at a stable core desktop that gets the work done, even if it doesn’t have all the bells and whistles that some of our users might be used to, yet.

)

Apart from “quite boring”, underlying “system stuff”, we’ve also worked on the visuals. In the video, you can see an improved contrast in Plasma popups, effects in kwin have been polished up to make the desktop feel snappier. We’ve started the work on a new Plasma theme, that will sport a flatter look with more pronounced typography than the venerable Air, and animations can now be globally disabled, so the whole thing runs more efficiently on systems with slow painting performance, for example across a network. These are only some of the changes, there are many more, visible and invisible.

We’re not quite done yet, but we have moved our focus from feature development to bugfixing, the results of that are very visible if you follow the development closely. Annoying problems are being fixed every day, and at this rate of development, I think we’re looking at a very shiny first stable release. Between today and that unicorn-dances-on-rainbows release lie almost three months of hard work, though, and that’s what we’ll do. While the whole thing already runs very smooth on my computers, we still have a lot of work to do in the integration department, and to translate this stability to the general case. Systems out there are diverse and different, and only wide-spread testing can help us make the experience a good one for everybody.

Are your Qt builds going OOM?

If you’re, like me, regularly building Qt, you probably have noticed a decent hunger for memory, especially when linking Webkit. This part of the build can take well over 8GB of RAM, and when it fails, you get to do it over again.

The unfortunate data point is that my laptop only has 4GB, which is enough for most (but one) cases. Short of buying a new laptop, here’s a trick how you can get through this part of the build: Create a swap file. Creating a swapfile increases your virtual memory. This won’t make it fast, but it at least gives Linux a chance to not run out of memory and kill the ‘ld’ process. Creating a swapfile is actually really easy under Linux, you just have to know your toolbox. Here’s the quick run-down of steps:

First, create an empty file:

fallocate -l 4096M /home/swapfile

Using the fallocate syscall (which works for newer kernels, but only for btrfs, ext4, ocfs2, and xfs filesystems), this can be done fast. In this example, I have enough space on my home partition, so I decided to put the swapfile there. It’s 4GB in size, which should be plenty of virtual memory to finish even the greediest of builds — your mileage may vary. If you’re not able to use fallocate, you’ll need a bit more patience and dd.

As your swap should never be readable by anybody else than root, change its permissions:

chmod 600 /home/swapfile

Next, “format” the swapfile:

mkswap /home/swapfile

Then, add it to your virtual memory pool:

swapon /home/swapfile

You can now check with tools like `free` or `top` (tip: use the much nicer `htop` if you’re into fancy) that your virtual memory actually increased. Once your build is done, and you need your disk-space back, that’s easy as pie:

swapoff /home/swapfile
rm /home/swapfile

If you want to make this permanent (so it’ll survive a reboot), add a line like the following to your fstab:

/home/swapfile none swap defaults 0 0

This is just a really quick tip, more details on this process can be found in the excellent Arch Wiki.