Planet KDE logo

Welcome to Planet KDE

This is a feed aggregator that collects what the contributors to the KDE community are writing on their respective blogs
To have your blog added to this aggregator, please read the instructions


4 December, 2020

So, I decided to do Advent of Code this year too. I usually get stuck part of the way, but I still think that it is a fun exercise.

This year the plan is to use python and pytest the whole way through. Every day that i learn something that I want to remember, I add a til.txt file in that sub-directory. You can follow my progress and learnings in the git repository.

The lessons this far includes:

  • When using readline to read lines, the line-break is included, so len(text) will be one character more than expected. Strip your strings!
  • When doing number of ifelifelifelif, make sure to include an else, even though you know that all cases are covered. I run assert False in the else clause.

As you can see, these are on the level of small snippets of wisdom right now. I’m sure it will be more interesting as the problems become more complex.

We are happy to announce the release of Qt Creator 4.14 RC !


2 December, 2020

 What does that mean?

It means this

That is, you add JPEG::JPEG to target_link_libraries, and that's it, no need to add the includes, the compile_definitions and whatnot.


This has multiple advantages to the old mode:

  • You can't misspell it, since these are actual things cmake knows about not strings so if you write something like JPEG::JPG it will fail at cmake stage
  • You won't forget to add the include (most of us did at some point) because you don't need to :)
  • The include path is just for that particular target (the old method added it to "everyone")
  • It's basically less lines so it's harder to do wrong


To know if you can use that you'll need to use the cmake help, for example the imported target is described at

Now we don't probably depend on cmake 3.19, do we? So we need to make sure the cmake we say we support has that, so use the combo on the top of that page to go and find which version introduced it, for JPEG we can see it was cmake 3.12

Four years ago I bought a OnePlus 2 for 319€, nowdays it still is good hardware, it's better or as good as most of the mid to low end phones in the market.


But it has a big-ish problem, it is stuck on Android 6, which not only is old and probably full of security holes, it is starting to not be supported by some apps.

Solution: LineageOS.

It provides Android 10 for my phone and works flawlessly (from what i can see, only been using it for 4 days), so the fact that "some randos" (with all my love, I'm a rando) can make it work, means that the manufacturer could have if they wanted, they just chose not to.

It's really sad because if i wasn't a geek that knew how to put LineageOS on the device i would have probably ended up buying a new phone, making the world be fill with more junk.

Let's hope the more open devices like the PinePhone KDE Community Edition put an end to this :)

I’ve now had my Lenovo ThinkPad X1 Yoga laptop for about 6 months, so I thought I’d provide a quick update about how it’s going to use this laptop every day with openSUSE Tumbleweed running KDE Plasma. Let’s explore what’s changed since then:


Initially, I complained about some aspects of the keyboard layout, but I’ve gotten used to the Home/End/PageUp/PageDown positioning, and the swapped position of the Fn and Ctrl keys. These are fine now. Lack of media keys is okay too since I’ve used the Shortcuts KCM to set my own. However I just can’t get used to the PrintScreen key being between the right Alt and Ctrl keys. I probably press it by accident 10 times a day and bring up Spectacle when I don’t mean to. One of these days I should get around to using xmodmap or something to turn it into a right Meta key, and they maybe make the F11 key which currently does nothing be the new PrintScreen key.

Speakers and audio

In my initial review, I had some complaints about the speakers and audio configuration. It turned out there there were issues both in the Kernel and PulseAudio that prevented the speakers from reaching their full potential, and all of those issues have been resolved now. The speakers sound awesome (for a laptop, of course). In addition, all the software issues in Plasma are fixed too. Everything audio-related is now perfect. I love listening to music on the machine. It sounds so good!


The camera’s lag has gone away due presumably to improvements in some layer of the software stack beneath KDE. The quality is still not fantastic, but that’s generally what you can say about any laptop webcam these days. It’s sufficient for Zoom and BigBlueButton meetings.

Power Management

Over the last 6 months, power management got worse and worse. Battery life continually declined and then eventually the battery started spontaneously reporting its charge percent as 0% while unplugged. At other times it would refuse to charge. This was a disaster for, well, actually using it as a laptop!

I called for warranty service and a technician replaced the battery recently. The issues immediately disappeared. I haven’t experienced any more buggy behavior, and the battery life has increased to about 6 hours with real use, which is probably acceptable given the fancy 4K screen. Hopefully there are more wins to be had through additional kernel optimizations in the future. I guess my original battery was just a lemon.



I love the 4K screen! Everything is so sharp and crisp!

..a little bit too much so, perhaps.

4K turns out to be kind of overkill for a 14″ screen. Its resolution of 3840×2160 pixels effectively becomes 1920×1080 with 200% scaling, but the thing is, 1920×1080 makes everything rather too small on the screen. It would be ideally suited for a larger 15.6″ screen, but at 14″ and even 13.3″, you need to use fractional scaling or increase the font size to make things big enough to be legible. So that’s what I’m doing: I currently have the scale set to 200% and I use 11pt fonts, making everything approximately 10% larger with no blurriness since it doesn’t scale icons, lines, or pixmaps. It’s as if I had an effective resolution of 1745×981.

Lenovo offers this laptop with a 1440p screen option, but that’s not right either: its 2560×1440 resolution, when scaled to 200%, gives you only an effective resolution of 1280×720, which is much too low and everything on the screen becomes comically large! Well maybe not comically large, but too large for my tastes, at least. 🙂 All windows need to be maximized, and even then, they will feel starved for space. This might be an acceptable resolution for a 12-13″ screen, but not 14″.

I think the ideal high DPI resolution for a 14″ lies between 1440p and 4K; something like QHD+, which is 3200×1800. You’d have effectively 1600×900 with 200% scaling, which would be perfect. 4K should be saved for the 15.6″ screen laptops which will have room to fit an enormous 90+ Wh battery required to provide adequate endurance with such a power-hungry panel.

There’s one more problem with the 4K screen: it’s driven by an integrated Intel UHD 620 GPU which simply cannot push the pixels fast enough. I regularly experience dropped frames and choppiness in full-screen GPU-accelerated animations. Even worse, full-screen CPU-bound rendering (like YouTube videos in Firefox) will kick the CPU into overdrive and massacre the battery life. Gaming? forget about it.

The situation would be improved with either Intel’s 11th gen architecture or AMD’s Ryzen CPUs, both of which feature radically better integrated graphics capabilities. But I’m stuck with the old Intel UHD 620 which is pathetically underpowered for the hardware that’s being thrown at it. Oh well. Lesson learned.

On a happier note, the touchscreen now works out of the box due to distro patches for the problem I mentioned in the initial review. However I still haven’t managed to get the 10-bit color support working.

High DPI scaling

Every single scaling issue I found is now (or already was) working on Wayland!

On X11, all the major issues I ran into are fixed, but there are still a lot of minor rough edges. Many are virtually unfixable, sadly. Ultimately Wayland is the future, so it’s good that it’s been selected as an official KDE goal and is improving at warp speed right now!


I’m happy with this laptop now. It does what I need and it’s a pleasure to use. Here’s what’s great about it:

  • Build quality
  • Quality of input and output devices: keyboard, touchpad, screen, and speakers
  • Uses LVFS for firmware updates (and this actually works)
  • Two full-size USB ports and a full-size HDMI port
  • Rechargeable pen that lives and charges in its own little garage

What would make it perfect:

  • Move the dang PrintScreen key to somewhere on the top function row, and maybe put a second Meta key in its current location
  • AMD Ryzen 4800U CPU for faster software compilation times and better integrated graphics
  • QHD+ screen resolution instead of 4K, for diminished power consumption and perfect 200% scaling
  • Even larger battery capacity; 51 Wh is not very impressive in a 14″ screen laptop anymore
  • USB-C ports on both sides so you can charge it from the left or the right

OpenUK is looking for two charismatic and diligent individuals to be judges in the 2021 OpenUK Awards. After a successful first edition in 2020, OpenUK are looking to find two judges from the Community to judge the Awards with Katie Gamanji, our head Judge for 2021.

To be considered as an OpenUK judge:

  • You will be someone who knows at least one of the Open Source Software, Open Data or Open Hardware spaces well, enjoys engaging with the communities and wants to see good projects, people and organisations recognised, and
  • You will be willing to spend some time reviewing circa 100 applications and to make a fair assessment of the applications, be able to present your decision to your fellow judges and then to present during the Awards ceremony charismatically.

The Judges’ work requires a dive deep into the nominations and diligent investigation of all of the applications to come to a well informed and balanced decision.

Nomination form is open now if you’d like to help or you can think of someone who would be suitable.


Web applications can be pretty useful at times when a native application is not available. In today’s tutorial, we will make an AppImage file of a web application using a tool called nativefier-appimage. nativefier-appimage makes it very easy to create AppImages of your favorite web applications and share them. It leverages the web application creation process by using nativefier. It packages the resulting web application in an AppImage for portability using appimagetool (which is included by default in Nitrux).

Note: We might change the name at some point if more features are added to the code (if needed).

Getting started

To make our AppImage for this tutorial, we will need to install npm.

  • By default, in Nitrux, npm binaries are installed in the Home directory.
sudo apt install npm --no-install-recommends

Now we need to download nativefier-appimage. After downloading the program, give it execution permissions.

  • Optionally move it to your $PATH, i.e., /usr/bin for system-wide access.
chmod +x nativefier-appimage
sudo mv nativefier-appimage /usr/bin

That’s all we need.

Making a web application

Now let’s create a web application. For this tutorial, we’ll create an AppImage of a WebGL game called HexGL. All we need to do is run nativefier-appimage, appending the name of the application and the URL.

nativefier-appimage HexGL

Our AppImage will be created, and now we can move it to ~/Applications so that it’s integrated into the desktop.

To test it, we launch it from the menu.

And it works!.

We even have support to use the global menu or the HUD.


  • By default, nativefier-appimage will add a generic icon taken from the website’s favicon; depending on the website, this might mean a low-res icon, the wrong icon is downloaded, or the icon is not displayed in the application menu. To work around this issue, you can add a custom icon to the web application AppDir.
    • In the image below, for example, I took a screenshot of the logo from the game using Spectacle; the capture area is 256×256 (it must be a standard size). The image must be saved to the AppDir; in this case, it’s HexGl.AppDir as icon.png (this is the default name) to the AppDir’s root (HexGL.AppDir/icon.png) and the resources folder (HexGL.AppDir/resources/app/icon.png). Then you can repackage the AppDir using appimagetool.
      appimagetool HexGL.AppDir

That’s it; this concludes today’s tutorial.

The post Making a web application AppImage in Nitrux appeared first on Nitrux — #YourNextOS.

PinePhone KDE Community edition pre-orders start from today, and we are continuously working on polishing the software that will be shipped with it.

Plasma Mobile is a user interface for phones and tablets, just like Plasma Desktop is for notebooks and desktop PCs.

There are various distributions that package Plasma Mobile,

Although there is some overlap between the Plasma Mobile and the KDE Neon team, Plasma Mobile is not tied to KDE Neon.

The Manjaro team has experience with the PinePhone hardware from building their images for the PinePhone shipping with Phosh. To provide the best Plasma Mobile experience, we decided to build on top of their work.

The KDE Community PinePhone will come with Plasma Mobile running on a customized installation of Manjaro ARM, giving you access to mobile applications from other environments already packaged in Manjaro, and the proven hardware support known from other Manjaro images.

If you would like to see a preview of what will be shipped with PinePhone KDE Community edition. You can download unstable nightly image from their website

We also aim to work with the KDE Neon and postmarketOS teams in the future to improve the support for Plasma Mobile in their distributions. This will ensure that you will be able to use Plasma Mobile in your favorite distribution.


30 November, 2020

Today is the day! — Nitrux 1.3.5 is available to download

We are pleased to announce the launch of Nitrux 1.3.5. This new version brings together the latest software updates, bug fixes, performance improvements, and ready-to-use hardware support.

Nitrux 1.3.5 is available for immediate download.

What’s new

  • We’ve updated the kernel to version 5.4.75.
  • We also offer the latest (as of this post) non-LTS kernel from our repository, currently 5.9.10.

  • We’ve updated KDE Plasma to version 5.20.3, KDE Frameworks to version 5.76.0, KDE Applications to version 20.08.3, and Qt 5.15.1.
  • We’ve replaced various default applications with their AppImage counterparts; these include LibreOffice, GIMP, Inkscape, Kdenlive, LMMS, and mpv. Eventually, all the default GUI applications will be exclusively AppImages.
    • Wine, appimagetool, and appimage-manager (app) are also AppImages, but they’re not a recent addition.
    • If you’d like to create your own AppImages, check this tutorial on our blog.

  • We’ve reorganized the default app menu folders to reflect the included applications in the distribution better.
    • The app menu allows for custom app folders. To customize the app folders, right-click the menu icon, select Configure NX Menu, and the tab Groups.

  • We’ve updated the included Maui applications (Index, Nota, VVave, Buho, and Station) to version 1.2.0. For more information about this new release, check the announcement on our blog.

  • We’ve updated Firefox to version 83.0.
  • We’ve updated GIMP to version 2.10.23.

Known issues


    • OpenGL acceleration is used by default if you use Nitrux in a VM, open System Settings>Monitor>Compositor, and select XRandr in addition to disabling desktop effects like Blur for better performance.
    • To utilize 3D acceleration in a hypervisor like VirtualBox, please use the guest additions ISO from Oracle, do not use the Debian packages from the repositories. For VMware Workstation and VMware Player, please use the package open-vm-tools-desktop from the repositories.
    • The managed locations (and thus the default) for AppImages in Nitrux are /Applications and ~/Applications.
    • AppImages launched from the application menu will be launched using firejail for sandboxing by default.
    • The default user and password are nitrux.
    • Changing the theme using the Global Theme KCM does not alter the Kvantum theme; to properly change the Kvantum theme, use Kvantum Manager.
    • The Kvantum theme does not pick up the color-scheme selected using the Colors KCM since the Kvantum SVG theme engine does not work like that. When Kvantum is used, the color-scheme is complementary to the Kvantum theme, as the theme is already providing the colors for the UI widgets.
    • Applications such as Discover and the Maui apps use QML and not QtWidgets like System Settings, Ark, KCalc, etc. So they are not themed to the full extent that QtWidgets apps are because Kvantum does not support QML adequately.
    • We include two layouts for the desktop, one is the default top panel and bottom dock, and the other is a single bottom panel; Latte Dock uses both. To change between them, right-click the dock or the panel. Using the Global Theme KCM and checking “Use desktop layout from theme” does not change the layout.
    • The Flathub repository is not added by default. However, it can be easily added using Plasma Discover by going to Settings>Add Source or using the terminal and entering the Flathub URL described in the Flatpak quick setup guide.
    • Nitrux is exclusively a 64-bit Linux distribution; however, software like Steam (32-bit) can be installed using Flatpak, and Windows software can be run using Wine. See using Wine in Nitrux.
    • When using the tiling windows feature (Khronkite), the system tray plasmoids will be treated as regular windows.
    • We’ve removed the Nvidia proprietary driver from the ISO file due to a bug with laptops using Optimus. Users that wish to use the Nvidia proprietary driver can do so by running the following commands post-installation.
      • The first command will install the driver, the driver settings program, and the PRIME command; the second will add our configuration of the Nvidia driver for X11.
      • sudo apt install -yy nvidia-driver-450 nvidia-settings nvidia-prime ubuntu-drivers-common
        sudo apt install -yy --reinstall nx-desktop-settings-legacy

Report bugs

To report bugs, please use our bug tracker at GitHub.

Changelog history

To see a list of previous changelogs, click here for the changelogs archived at our site, or click here for the changelogs archived at Sourceforge.

The post Changelog: Nitrux 1.3.5 appeared first on Nitrux — #YourNextOS.

With Qt 6 well on its way, it’s about time we go over some of the internal changes and optimizations made to Qt 3D for the upcoming release.

In a separate article, my colleague Mike Krus has already highlighted the API changes we’ve made in Qt 3D for Qt 6. This post will dive into the internal changes.


Goodbye Render Thread!

Back in 5.14, we got rid of the Aspect Thread. Yet we still had a Render Thread. On paper, having a dedicated thread would allow you to send drawing commands to the GPU while preparing commands for the next frame. This could potentially help with maintaining a high frame rate, if command submission took a long time. In practice, this worked only in the case that Qt 3D was used as standalone (without QtQuick).

The Qt Quick renderer has blocking synching points. Synching Qt Quick and Qt 3D content forces us to wait for all drawing commands to have been performed before proceeding to the next frame. Not only does this make having a RenderThread pointless, but it also results in separate code paths to handle Qt 3D driven by QtQuick.

Moreover, having an extra thread also adds a cost with general synchronization, scheduling, and memory allocations. In addition, the more threads you have, the more things get complex and hard to troubleshoot. For these reasons, we decided that whatever little speed gain we obtained from having a Render Thread didn’t justify keeping it.

In essence, this means that Qt 3D for Qt 6 only uses the main thread and a thread pool to spawn jobs in every frame. The rendering either takes place in the main thread or in the QtQuick SceneGraph thread, if using QtQuick.

Always favor the std containers

The backend of Qt 3D made heavy use of the Qt containers, like QVector and QHash. Much to our surprise, it appeared that QVector was adding a little bit of overhead everywhere we used it (mostly because of copy on write checks). Lots of something small can add up to something big. We were actually paying a high cost simply by using QVector.

Therefore, we’ve switched to using std::vectors in most of the Qt 3D backend. This work started with 5.15 and was pursued for Qt 6, as well. The API is not as nice as that of Qt’s vector but we have seen noticeable improvements in critical code paths on complex scenes. In contrast with the backend, the public API still relies on QVector (well QList in Qt6).

Use Rendering Abstractions


The Qt 5 architecture is tightly tied to OpenGL. Hence, our efforts with Qt 3D were primarily focused on providing an efficient OpenGL renderer. Towards the end of the Qt 5 series, The Qt Company started working on abstracting access to various graphics APIs with RHI (Rendering Hardware Abstraction).

In Qt 6, the tight coupling with OpenGL in the code will be removed in favor of calls made through the RHI abstraction layer. This signifies that Qt and, more specifically, Qt Quick will be able to work with different rendering backends (DirectX, Vulkan, OpenGL, Metal), depending on the target, the platform, and what’s available.

Qt 3D Render Plugins

Over the past couple of Qt releases, under the hood Qt 3D has slowly been reworked. The aim being to decouple the rendering from the processing code. In that sense, a plugin mechanism was introduced to load the renderer as a plugin. This has been finalized for Qt 6 and the existing OpenGL renderer is now a dedicated plugin. In parallel, we’ve started working on a new RHI-based render plugin.

The plan for Qt 3D for Qt 6 is to have the RHI-based renderer become the default. However, you will still be able to use the OpenGL render plugin if you wish to. A lot of work has been put into the OpenGL renderer and it is currently more mature and feature complete that what can be done with the RHI plugin. In reality, for most use cases, the RHI renderer will probably be enough.

API-wise this has little impact on code. The only changes required to have Qt 3D work with the RHI backend is to define a RHI compatible QTechnique on custom QMaterial classes. The default materials provided in the Qt 3D Extra modules have been updated.

Of course, this plugin mechanism will also allow you to have dedicated renderers for Metal or Vulkan, if the RHI plugin is deemed insufficient.

Selecting a Render Plugin and a RHI backend

By default, Qt 3D will try to load the RHI plugin and let RHI decide which backend to use. However, that behavior can be overridden by using the following environment variables and values:

    • rhi
    • opengl
    • vulkan
    • metal
    • opengl
    • d3d11

Note: When using Scene3D, the OpenGL plugin should only be selected if you’re forcing RHI to use its OpenGL backend.

RHI Limitations

The development of RHI is driven with the use cases of Qt Quick and Qt Quick 3D in mind. This implies that not all the features required for more advanced use cases are available.

API limitations

When it comes to Qt 3D, this means that what the FrameGraph API allows you to describe might not be translatable to existing RHI commands.

  • No way to explicitly Blit (you have to blit manually by rendering a quad into a framebuffer)
  • MemoryBarrier cannot be set explicitly
  • Not all Texture Formats are available
  • Draw Indirect is currently not supported
  • Geometry Shaders are currently not supported.
  • Different RHI backends support might support different feature set.

Technical limitations

No Multithreading Support

One of the interesting features of modern graphics APIs, such as Vulkan, is the ability to use several threads to build the list of rendering commands. This maps perfectly to Qt 3D’s multithreaded architecture. Unfortunately, RHI does not currently support multithreading. Due to this limitation, while Qt 3D still leverages multiple threads to prepare commands, it needs to serially generate the RHI commands from a single thread. As a result, things are not likely to be any faster than what was achieved with the OpenGL renderer when it comes to command generation and submission. Arguably, there might still be a gain if the driver works better with whichever RHI backend gets used.

Limited feature set available with OpenGL backend

The OpenGL backend maps only to the ES 2 / GL 2 feature set.

Limitations on partial clears of a render target

Another hurdle with the current implementation is it limits each render target to a single clear call. For instance, you cannot clear the depth buffer after having drawn something. Given that, the workaround is generating more render targets and attachments than would otherwise be required and manually blitting between these.

Summing Up

As can be seen, a fair amount of work has been ongoing these past few months. From new performance optimizations in the backend to new decoupled rendering plugins, Qt 3D is ready for the next major Qt release. While most of these changes will be transparent for Qt 3D users, they still represent nice improvements.

KDAB provides a number of services around Qt 3D, including mentoring your team and embedding Qt 3D code into your application, among others. You can find out more about these services here.

About KDAB

If you like this blog and want to read similar articles, consider subscribing via our RSS feed.

Subscribe to KDAB TV for similar informative short video content.

KDAB provides market leading software consulting and development services and training in Qt, C++ and 3D/OpenGL. Contact us.

The post Qt 3D Renderer changes and improvements in Qt 6 appeared first on KDAB.