Neon OEM Mod…arghhh

For years and years already Ubuntu’s installer, Ubiquity, has an OEM mode. And for years and years I know it doesn’t really work with the Qt interface.

An understandable consequence of not actually having any real-life use cases of course, disappointing all the same. As part of the KDE Slimbook project I took a second and then a third look at the problems it was having and while it still is not perfect it is substantially better than before.

The thing to understand about the OEM mode is that technically it splits the installation in two. The OEM does a special installation which leads to a fully functional system that the OEM can modify and then put into “shipping” mode once satisfied with the configuration. After this, the system will go into a special Ubiquity that only offers the configuration part of the installation process (i.e. User creation, keyboard setup etc.). Once the customer completed this process the system is all ready to go, with any additional software the OEM might have installed during preparation.

Therein lies the problem in a way. The OEM configuration is design-wise kind of fiddly considering how the Qt interface is set up and interacts with other pieces of software (most notably KWin). This is double true for KDE neon where we use a slightly modified Ubiquity, with the fullscreen mode removed. However, as you might have guessed, not using fullscreen leads to all sorts of weird behavior in the OEM setup where practically speaking the user is meant to be locked out of the system but technically he is in a minimal session with a window manager. So, in theory, one can close the window, when started the window would be placed as though more windows are meant to appear, and it would have a minimize button etc. etc. All fairly terrible. However also not too tricky to fix once one has the identified all problems. Arguably that is the biggest feat with any installer change. Finding all possible scenarios where things can go wrong takes days.

So, to improve this the KDE Visual Design Group‘s Jens Reuterberg and I again descended into the hellish pit that is Qt 4 QWidget CSS theming on a code base that has seen way too many cooks over the years. The result I like much better than what we started out with, even if it isn’t perfect.


The sidebar has had visual complexity removed to bring it closer to a Breeze look and feel. Window decoration elements not wanted during OEM set up are being removed by setting up suitable KWin rules when preparing for first boot.

Additionally, we will hopefully soon have enough translations to push out a new slideshow featuring slightly more varied visuals than the current “Riding the Waves” picture we have for a slideshow.

For additional information on how to use the current OEM mode check out the documentation on the KDE UserBase.

Ubiquity code
Slideshow code (most interest translations setup this)


Neon 5’s Many PPAs & APT

Project Neon 5, the KDE Frameworks 5 version of Kubuntu‘s continuous KDE software  delivery system, has more than one package repositories balancing quality and update frequency in different ways. This post is supposed to help those of you who, like me, wish to use whatever works best and therefore need to switch PPAs from time to time.

APT really comes in handy for this. As it allows you to pretty freely move between versions of a package through increasing pinning priority on a different PPA.

First you add all three repositories and create a file /etc/apt/preferences.d/kf5 containing:

 Package: *
 Pin: release o=LP-PPA-neon-kf5-snapshot-weekly
 Pin-Priority: 350

Package: *
 Pin: release o=LP-PPA-neon-kf5-snapshot-daily
 Pin-Priority: 250

Package: *
 Pin: release o=LP-PPA-neon-kf5
 Pin-Priority: 150

Now all you need to do is increase the priority of any of the entries to switch to that snapshot and run

sudo apt-get update && sudo apt-get dist-upgrade

APT will then automagically move your entire KDE Frameworks 5 stack to the version in the PPA with the highest priority.

So magic.