Main menu:


Please consider a small donation:



Or you can donate bitcoin:


Thanks to TekLinks in Birmingham, AL, for providing colocation and bandwidth.

Page Rank


FOSS Force Best Blog--2013 Award

Recent posts

Recent comments

About this blog

I am Eric Hameleers, and this is where I think out loud.
More about me.


Subscribe to Blog via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Join 422 other subscribers

My Favourites



March 2019
« Feb    

RSS Alien's Slackware packages

RSS Alien's unofficial KDE Slackware packages

RSS Alien's multilib packages

RSS Slackware64-current



Thinking about working on KDE 5 again (frameworks, plasma, applications)

qt-kde-620x350During these final days of my relatively long Christmas holiday, I have started looking at the KDE 5 build scripts again. KDE 4 has seen its final release sometime ago, and Patrick shows no signs of updating the KDE in slackware-current, so in order to bring some fresh excitement to KDE users on Slackware, I am pondering an update of the “testing” repository aka the KDE5 repository.

In December, the KDE community released the first tarballs of the “Applications” which is the first step to completion of the new KDE 5 desktop. Remember: the Frameworks 5 came first (a set of modular libraries that expand the functionality of Qt5), Plasma 5 builds a desktop workspace on top of the Frameworks, so that had to come next, and finally there are the Applications which are now ported from the KDE 4 Development Platform to Frameworks 5 slowly.

In particular that recent release of Applications 14.12 (the notation used here is gave me some headaches. Most of these applications are familiar from KDE 4, and only a few are now ready for the Plasma 5 desktop workspace (Kate and KWrite, Konsole, Gwenview, KAlgebra, Kanagram, KHangman, Kig, Parley, KApptemplate and Okteta). It is impossible for me to separate the KDE 5 applications from the KDE 4 applications. Their names have not changed, and whereas I needed to rename a few packages in Frameworks and Plasma in order to prevent a clash with package names in the KDE 4 set, I do not want to do the same for the Applications. After all, when running Plasma 5 you do not want to see both KDE 4 and Plasma 5 versions of the Konsole application in your desktop menu – just the Plasma 5 version. Also, compiling these “Applications 14.12” will cause a lot of KDE 4 packages to be overwritten – for example, marble-4.14.3 with marble-14.12.0 et cetera. That is a one-way road. I can not think of a clean method of separating the old and the new.

In my “preview” of KDE 5, I was able to offer the KDE 5 packages as co-installable to KDE 4 because it was not yet more than Frameworks and Plasma packages – it needed the presence of KDE 4.x in order to provide a meaningfull Plasma 5 workspace. That meant, you could install KDE 5, play around with it for a bit, and then un-install the packages if you had seen enough, without this process touching or destroying the configuration of your KDE 4 environment. That was a good thing, because Plasma 5 was quite unstable at that time, and the whole exercise was not meant to probide an actual day-to-day work environment.

We are now 5 months further in time, and the current state of Frameworks/Plasma 5 combined with the new set of Application releases, should provide a stable platform that is slowly migrating from KDE 4 to 5.

That is why I decided to not stretch my luck and try another co-installable version of KDE 5 but instead go all the way and provide a full upgrade from KDE 4.14.3 to Frameworks/Plasma/Applications. It will take a while because of all the unknowns, but I think I have done most of the preparations now (gathering all the sources, updating the build scripts). It will be a matter of compiling, fixing failures and retracing issues to their resolution.

I think I will also provide scripts for an easy roll-back from the new KDE 5 packages to either the default Slackware packages or else my KDE 4.14.3 packages.

Note that this is going to be relevant and beneficial only to people who are running Slackware-current (our development version) so if you are going to want to try this later on, you need to know what you are up to. Once you will upgrade from KDE 4 to my new KDE 5 packages, it may not be trivial (i.e. without cleaning out your ~/.kde and ~/.local directories) to downgrade at a later point in time.

End transmission.



Comment from Mike Langdon (mlangdn)
Posted: January 8, 2015 at 02:59

I’ll take the plunge! I really didn’t want to get it on the first of KDE-5, but if the whole thing is ready (or somewhat ready) I’m in. 🙂

Comment from Michelino
Posted: January 8, 2015 at 16:27

I’m using your kde5 preview since September, with not so much problem, so I can’t wait the upgrade!!!!

P.S.: Je suis Charlie

Comment from Altor
Posted: January 12, 2015 at 12:59

Hi Eric,
good to know that you continue to work on Slackware and especially KDE5.
Good luck and I’m waiting for more news !


Comment from alienbob
Posted: January 12, 2015 at 13:10

My activities on the KDE 5 testing are visible in (you may have to force-refresh that page because Akamai caches it).

Pingback from Alien Pastures » Using git while working on KDE 5
Posted: January 14, 2015 at 00:49

[…] Thinking about working on KDE 5 again (frameworks, plasma, applications) […]

Comment from Judi
Posted: May 30, 2015 at 03:18

What do Linux users really need to have productivity? Does that really mean using something as big and bloated as Gnome or KDE?


I’d personally love to see Slack ditch the likes of KDE too and consider replacing it wirh something like Cinnamon or Budgie…

For those that don’t know Budgie have a look;

I stopped using Desktops in Linux 10-15 years ago, I just use a WindowManager as my DE. To me, if you need a big DE, then you need Windows! 🙂

Comment from alienbob
Posted: May 30, 2015 at 12:50

Hi Judi

I don’t know what your definition of “bloat” is? Bloat to me means, addition of lots of unnecessary software that get in your way, decrease your system’s speed and responsiveness, mess with your productivity and are a general annoyance.

KDE is not that. You get a lot of tightly integrated software that works well. There is no sense of slowness or sluggishness, and memory consumption tests performed in the Slackware forum on LQ prove that KDE actually uses less memory than other modern Desktop Environments.

Budgie integrates very tightly with the GNOME stack according to their own web site, which is a design choice but it causes PAM and systemd to be drawn in. And Cinnamon is a forked GnomeShell so it carries the whole tainted GNOME history with it as well.

See, I can bring arguments to the table against both of them, just like you do for KDE. But in the end, everyone should choose whatever Desktop Environment fits most with the style of work he or she performs. Having that luxury of choice, is what this is all about. There are many people involved with the broader Linux landscape who are opposing exactly that idea of “freedom of choice” and instead work toward “freedom from choice” where you think you can still make choices but the actual number of choices is becoming ever more limited.

Slackware, or the Slackware team, is not trying to limit your choices. There is a design behind the core distro, and currently KDE fits within that design, but it is extensible and there are several choices of DE’s that you can obtain from 3rd party repositories.

If at this point you still think that MS Windows is a better choice than the KDE desktop, then I stop taking you seriously and this will be my first and last answer to you.

Write a comment