Icemon 3.2.0 release

Here's a new minor release of Icemon: 3.2.0.

One big bug fix addressing problems with the scheduler discovery in newer Icecream releases and small coding style improvements.

Here's the changelog for the 3.2.0 release:


- Fix broken scheduler discovery with newer Icecream (#40)

Internal Changes:

- Add some badges to
- Coding style improvements

Get it:


Tips for streamlining KDE applications for deployment on Microsoft Windows

In KDE we have a great group of developers hacking on a variety of applications. We usually have no problems getting our software out to end users on Linux because distributions help us packaging and distributing our software.

Where we do have problems, for the major applications, is ensuring our software works on other platforms such as Windows and macOS. This short guide gives a few tips to understand how to make your KDE pet project work on Windows by at least testing it once on said system and verifying a few basic things.

Build your application on Windows

Set up a Windows VM (Windows 7+), a compiler (MSVC2015+ (recommended) -- or let Craft auto-setup MinGW during bootstrap) and build your application using Craft. If set up properly, all you need to do now is to run something along:

craft filelight  

Craft will take care of installing all dependencies required to build filelight (i.e. deps of Qt5, Qt5, deps of KF5, KF5, ...) and only then builds the filelight project.

The end result is one single install root which contains the images of every package you've just built. Now starting filelight is as easy as running this in the terminal:


Run the unit tests

Again, easy to do with Craft. If your pet project has some unit tests availabe, you can easily run them by invoking e.g.:

craft --test kcoreaddons  

This will invoke ctest in the correct build directory and run the project's test suite.

Package the application

Craft on Windows has functionality to create installers out of installed packages.

craft --package filelight  

The way this is implemented is pretty simple but powerful

  • Craft collects all files of every image directories of the packages your application depends on
  • Craft collects all files of the application's image directory
  • Craft puts them into an intermediate install root.
  • After that, Craft will strip unneeded files according to blacklists (cf. 'blacklist.txt' and similar functionality in blueprints)
  • After that custom scripts may be run
  • After that makensis is called (from the NSIS installer framework) which basically zips up the whole install root and generates a final installer executable

Things you usually need to fixup

Installer icon

Handled by: Craft

The very first impression counts, so why don't make your installer binary as sexy as possible?

Again let's take the installer generated for filelight. One version without an installer icon set, and one with the filelogo set as logo:

Before: No installer icon
After: With custom installer icon

This is very easy to do with Craft which contains a few helpers to instruct the NSIS installer framework (the scriptable tool we use to generate Windows installers to begin with) properly to our likings.

An exemplary patch in craft-blueprints-kde.git (KDE's blueprint collection for Craft):

commit 1258a4450a1ee2f620856c150678dcaf5b5e7bad  
Author: Kevin Funk <>  
Date:   Mon Nov 20 14:13:04 2017 +0100

    filelight: Add application icon

    Created with:
      convert /usr/share/icons/breeze/apps/48/filelight.svg ./kde/kdeutils/filelight/filelight.ico

diff --git a/kde/kdeutils/filelight/filelight.ico b/kde/kdeutils/filelight/filelight.ico  
new file mode 100644  
index 0000000..1b6a71b  
Binary files /dev/null and b/kde/kdeutils/filelight/filelight.ico differ  
diff --git a/kde/kdeutils/filelight/ b/kde/kdeutils/filelight/  
index 0003f30..ac602c6 100644  
--- a/kde/kdeutils/filelight/
+++ b/kde/kdeutils/filelight/
@@ -30,6 +30,7 @@ class Package(CMakePackageBase):
         self.defines["productname"] = "Filelight"
         self.defines["website"] = ""
         self.defines["executable"] = "bin\\filelight.exe"
+        self.defines["icon"] = os.path.join(self.packageDir(), "filelight.ico")

         self.ignoredPackages.append("libs/qt5/qtdeclarative") # pulled in by solid

This patch adds an ICO file to the repository and references it in the filelight blueprint. Craft takes care of telling NSIS to use this ICO file as the installer icon internally while building your package with craft --package filelight.

Application icon

Handled by: CMake

Imagine starting your application via the Windows Start Menu:

Before: No application icon
After: With custom application icon

For getting the custom application, you need to embrace using Extra CMake Modules ECMAddAppIcon module which provides the CMake function ecm_add_app_icon(...) which in turn allows you to amend your executable with an application icon.

Here's an exemplary patch taken from filelight.git:

commit d7c7f1321547197e5bb9ceba6b8ccc51790bef8b  
Author: Kevin Funk <>  
Date:   Mon Nov 20 23:14:30 2017 +0100

    Add app icon

diff --git a/CMakeLists.txt b/CMakeLists.txt  
index 4c1e5dc..b8b6eda 100644  
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -25,6 +25,7 @@ cmake_minimum_required (VERSION 2.8.12 FATAL_ERROR)
 find_package(ECM 1.3.0 REQUIRED NO_MODULE)

diff --git a/src/CMakeLists.txt b/src/CMakeLists.txt  
index 622c9d8..06f5e8d 100644  
--- a/src/CMakeLists.txt
+++ b/src/CMakeLists.txt
@@ -34,8 +34,16 @@ set(filelight_SRCS
-    main.cpp)
+    main.cpp
+    ${CMAKE_CURRENT_SOURCE_DIR}/../misc/16-apps-filelight.png
+    ${CMAKE_CURRENT_SOURCE_DIR}/../misc/32-apps-filelight.png
+    ${CMAKE_CURRENT_SOURCE_DIR}/../misc/48-apps-filelight.png
+    ${CMAKE_CURRENT_SOURCE_DIR}/../misc/64-apps-filelight.png
+ecm_add_app_icon(filelight_SRCS ICONS
+    ${filelight_ICONS})
 ki18n_wrap_ui(filelight_SRCS dialog.ui)
 add_executable(filelight ${filelight_SRCS})

Use Breeze icon theme

Handled by: Craft -- you don't need to do anything.

Breeze-icons (KDE's default icon theme), when configured with te CMake option -DBINARY_ICONS_RESOURCE=ON, installs .rcc files (binary resources, loadable by Qt).

Craft by default passes -DBINARY_ICONS_RESOURCE=ON when the breeze-icons package is installed and thus the RCC file is available by default. When a Craft blueprint using breeze-icons is packaged, the RCC file is automatically included in the resulting artifact.

When the application starts up, KIconTheme scans some directories for RCC files, and if it finds them they're automatically opened and loaded => icons are available.

Further reading about the initial design of the feature by David Faure:

Check presentation of file paths in user interface

Make sure that file paths in your application are rendered consistently. One usual problem we face is that the user interface ends up with strings like C:/Program Files (x86)/KDevelop\, which makes use of forward and backward slashes inconsistently.

Bad: Mixed forward/backward slashes in file paths

Instead, decide for one form of slashes. While on Windows backward slashes are the usual form; the Qt framework makes it a little difficult to print path names with them. API such as QUrl::toDisplayString(...) will always return paths using forward slashes, and one would need to add little helpers everywhere using QDir::toNativeSeparators to do it properly.

At the very minimum use either form; don't mix forward and backward slashes in one file path. Applications on Windows these days handle paths containing forward slashes just fine, by the way.

commit 0de04d386e403ded74554951a8c4dcb9ee9bc1f9  
Author: Kevin Funk <>  
Date:   Mon Nov 20 15:32:54 2017 +0100

    File::fullPath: Nicer file path on Windows

diff --git a/src/fileTree.cpp b/src/fileTree.cpp  
index 9a5d06e..28ed689 100644  
--- a/src/fileTree.cpp
+++ b/src/fileTree.cpp
@@ -21,6 +21,8 @@

 #include "fileTree.h"

+#include <QUrl>
 File::fullPath(const Folder *root /*= 0*/) const
@@ -32,5 +34,6 @@ File::fullPath(const Folder *root /*= 0*/) const
     for (const Folder *d = (Folder*)this; d != root && d; d = d->parent())

-    return path;
+    const QUrl url = QUrl::fromLocalFile(path);
+    return url.toDisplayString(QUrl::PreferLocalFile | QUrl::StripTrailingSlash);

Install C/C++ runtime

Handled by: Craft -- you don't need to do anything.

When installing an application on Windows, the package author also needs to make sure the appropriate C/C++ runtime is injected into the system as part of the installation process. For instance, if your project was compiled using Microsoft Visual C++ 2015 and you want this project to run on another machine, you need to make sure the Microsoft Visual C++ 2015 Redistributable (which contains the C/C++ runtime components) is installed there.

Packages we need on Windows:

  • If project compiled with MSVC:
    • VCRedist installer (contains all necessary libraries)
  • If project compiled with MinGW:
    • Needs another set of libraries (e.g. libstdc++-6.dll, libgccssjlj-1.dll, ...)

But, don't be desperate: Craft has that all covered and will automatically include the binaries for either C++ runtime in the package and make sure it is properly installed as part of the installation of your KDE application on the target machine.

More ideas

If you'd like to know anything else I can probably add a few more paragraphs to this blog post for future reference. Just comment / mail me!

CI for Windows installer and macOS bundle generation: KDE Binary Factory

For some time now the KDE community has had a separate Continuous Integration system running which repeatedly generates Windows installers and macOS app bundles (DMG) for a specific subset of KDE projects.

For a starter, all the KDevelop on Windows releases (read: 32-bit and 64-bit NSIS-based installers) are nowadays generated on this CI and the binary blob which falls out of this process is used as official Windows release installer on the KDevelop website.

So, what exactly does KDE's Binary Factory do, and how does it work -- and why was it created to begin with?


With the move to KF5 it became easier to get KDE applications running on non-Linux systems. With the very-much needed split of kdelibs into smaller components, it is now easier to pick & choose what to use on these platforms -- so arguably it is easier to cut out unwanted dependencies (think of DBus, KDE service daemons, ...) on these platforms and stop packaging them at all.

Still, the process of getting a reproducible build of KDE project X on either Microsoft Windows and/or macOS has always been a daunting task. Lots of energy went into KDE's Craft (an open source meta build system and package manager, primarily but not only focused on C++ projects) lately which also helped streamlining this process.

It has never been that easy to generate installers or app bundles for any KDE project (where Craft has a recipe for) using Craft. The missing bit was automating all this by using Craft on Continuous Integration system.

Introducing the KDE Binary Factory

KDE's Binary Factory is a Continuous Integration system primarily created for generating Microsoft Windows installers and macOS app bundles. It has no relation to KDE's CI system other than by sharing some of the machines of the CI workers. The jobs on the Binary Factory are mostly generated manually -- adding projects is very easy though.

How does it work?

First of all, the Binary Factory doesn't really know how to build a particular project. The logic for that -- i.e. which dependencies need to be there, which CMake arguments should be used etc. pp. -- is all stored only in Craft blueprints.

The Binary Factory has a set of projects for which Jenkins will trigger jobs on a nightly basis. It does not do much more than calling Craft like this each night:

# exemplary Windows job for kbruch

# rebuild kbruch
python "C:/Packaging/craftroot32/craft/bin/"  -v --fetch --unpack --compile --install --qmerge  kbruch

# after that, package kbruch (create a Windows installer)
python "C:/Packaging/craftroot32/craft/bin/"  -v  --package kbruch  

If there would be missing dependencies for kbruch, or dependencies out of date, Craft would automatically install or update the depedencies, resp.

After the package has been created, Jenkins is instructed to archive the result. You can easily grab the freshly generated installer on the job page, for instance: which usually shows something alike:

Last Successful Artifacts  
    kbruch-17.08.3-windows-msvc2017_32-cl.exe   32.65 MB    view

One click there and the download of the installer starts.

How do I add my pet project?

If you do want your project to be on the Binary Factory, add a recipe (documentation here) and then notify me.

I'd urge you to try building your pet project on Windows yourself first, via Craft, so we don't need to play ping-pong with the CI too much. You (the "project owner") are responsible that the Craft blueprint for your project is up-to-date and works.

Now what to do with the installer/bundle?

The Binary Factory generates Windows installers and macOS bundles at this point. Now what I would not like to see (what already happened) is that individual projects just link to the Binary Factory job pages and tell people 'here, this is the official release of project X'. You shouldn't just link to untested binaries.

Instead I'd like to establish this workflow for project owners:

If there's a release of, say, Kate:

  1. Project owner waits for or triggers a build of Kate on the Binary Factory
  2. Project owner verifies that the installer/bundle works(!)
  3. Project owner uploads the install/bundle on the KDE FTP into the correct project folder
  4. Project owner then adds links to the newly uploaded files on the FTP to the project homepage

Note: Of course linking to the Binary Factory to point users to 'nightly builds of project X' is of course fine -- we do that for KDevelop, too.

Why should I use the Binary Factory?

It has some nice benefits:

  • Automated nightly installer/bundle generation for your project, if set up properly
  • Automated signing of installers/bundles with a KDE-wide code signing certificate
    • Avoids false-positives in AV scanners, warnings by Windows SmartScreen, etc. pp.
  • No need to run a Windows or macOS CI yourself, for package generation
  • Kept up-to-date implicitly via Craft features
    • I.e. right now we're using Qt 5.9.1, KF5 5.37.0
  • It's all there already -- you just need to use it!

Future plans

Start generating macOS bundles

We have a macOS worker set up, but unfortunately the DMG package generation for macOS is still somewhat broken in Craft. We need to sit down and work on this. I don't think there's a lot work left; we can actually create macOS bundles just fine for KDevelop, but there are a few problems with missing shared libraries and/or wrongly set up library metadata (RPATH, etc.).

For the time being, the main focus is on providing Windows installers, but we'll have a look into providing macOS bundles soon-ish now.

Start releasing Windows installers

A couple of KDE projects would be really nice to have on Windows, and actually quite a few installers generated by the Binary Factory are already usable!

One prime example, Filelight:

Setting up a job on the Binary Factory for generating the installer for Filelight literally took me a few hours (for preparing the Craft blueprints, injecting the job in Jenkins -- that's it). Now we just need to link the installer on the official Filelight homepage.

Final words

I'm happy to see this finally working in an automated way. At least for the KDevelop team, the automated installer generation for the KDevelop installers has been a major step into the right direction. After a couple attempts of doing that on personal machines where we literally always managed to break our setup, we now have a clean, automated process of generating them on a isolated machine.

I hope the Binary Factory can be useful to other KDE projects as well. I'm happy to help you guys out to set up jobs on the CI so your personal projects can be built.

Trip report: Google Code-In 2016 Summit at Google headquarter

Heya fellow KDE people,

just a couple of weeks ago I got the opportunity to attend the Google Code-In Summit held in several locations scattered around the San Francisco Bay area. I can tell you first hand: It's been an awesome trip and I encourage anyone else to participate if the opportunity arises.

What is Google Code-In?

Google Code-In (GCI) is a contest which introduces pre-university students (ages 13-17) to open source software development. The event features a wide range of small beginner tasks, which allows students to jump into contributing to open-source no matter what skills they have. Experienced Mentors of participating organizations (hey, KDE!) help out scheduling the work and give useful tips to the newcomers.

This year, GCI has seen 1,340 students from 62 countries, and they completed an impressive number of 6,418 tasks. 17 organizations participated, amongst them were for instance Wikimedia, Drupal, FOSSASIA, (...) and of course KDE!

The summit

Each year, after GCI concluded, Google invites one mentor plus two Grand Prize winners of each participating organization to San Francisco, for the Code-In Summit. The Grand Prize winners of each org are selected by the organizations themselves: those students have completed a huge of number of tasks and/or otherwise performed exceptionally well.

Picture of Grand Prize Winners of GCI
The Grand Prize Winners of Google Code-In 2016

Each one of those Grand Prize winners, including their parents, were flown in to the US west coast for four days this summer to meet their mentors and connect with Google engineers.

The four days were quite packed, I'll try to summarize what happened throughout this event

Day 1: Meetup

Day 1 started late in the after noon, where all students and parents, as well as all mentors were invited to the Google San Francisco office for a first get-together. Remember, most of the students haven't met each other or the respective mentor before. After clarifying why we're here and what we're going to do the next days, Stephanie et. al from Google organized a little icebreaker game so we actually got to know each other.

First time I met my great fellow KDE GCI Grand Prize Winners, Ilya and Sergey, too. Congratulations on your award!

Oh, and of course we all got covered with tons of Google Swag and food afterwards.

Day 2: Award ceremony and talks

The second day started (way too early, yawn) at 7:15 AM, sharp, at the lobby of our hotel. We were transferred to the main Google Campus at Mountain View afterwards, where the Award ceremony with lots of other Google engineers started.

Chris DiBona, Director of Open Source at Google, held a talk highlighting the importance of the Open Source programs Google is sponsoring each year, thanking all the participants -- both mentors and students. Both Google Code-In and Google Summer of Code are immensely successful programs which introduce more and more students to the Open Source world each year.

After this, Chris DiBona and his team went through all the organizations and awarded each Grand Price winner with a trophy. Chris made it very clear that each of those students did his or her job extremely well, which is the sole reason he or she could attend this event. The parents of course were super proud of their children, and took the opportunity to take tons of photos during the whole ceremony.

Picture of KDE's Grand Prize Winners of GCI
Sergey Popov (left) and Ilya Bizyaev (right), proudly presenting their GCI trophy.
I didn't get a trophy, d'oh!

Both Sergey and Ilya completed around 20 tasks during the GCI period and both showed some impressive enthusiasm, commitment and competence.

Again, congratulations to all the Grand Prize winners, but especially to "our" guys of course -- thanks for participating and helping out in KDE!

The rest of the day was fully packed with talks from Google engineers, a couple of them quite interesting even for the majority of mentors. We got an introduction to Waymo, Google's self-driving car and introduction to how 'to become a Kernel developer' by Grant Grundler (from the Chrome team). After that, an introduction to Open Source Compliance by Max Sills (attorney at Google) -- which led to a little heated discussion initiated by attendants about the usefulness of the Affero General Public License -- hint: Google doesn't like it at all) and a serious discussion about the WTFPLDo What the Fuck You Want to Public License, which is despite its funny touch is actually not recommended to use, especially in the US, since it doesn't clearly deny liability. Could get you in trouble.

Lunch time!

... and of course, more photos, and a short walk around the Google campus, checking out all the various cafeterias and other tourist attractions.

KDE Grand Prize Winners with Android mascot
Ilya and Sergey again!
Picture the whole GCI summit attendants
This time, a picture of all the GCI attendants: Students, parents and mentors together (Picture: Josh Simmons)

More talks after lunch: A couple of talks about how working at Google is like, how the recruitment process works. Next was a short overview over Oppia, Google's open interactive learning platform, backed by artificial intelligence by Sean Lip and last but not least, an introduction to TensorFlow, and open-source library for machine learning, by Andrew Selle.

All in all, a couple of pretty insightful talks, surely impressive to the students, I'm happy those Googlers found the time to present their projects.

After that, of course more tasty food, a short visit to the Google visitor center + merchandise store and then we were on our way back to San Francisco downtown again.

Day 3: Activity

Day 3 was the activity day, where one group could spent the day visiting the Exploratorium, the Museum of Science, Art and Human Perception, one of the biggest attractions in SF, the other group could ride a Segway next to the piers.

All of KDE of course opted for the Segway ride, which was a fun experience. Especially for the student's parents of course, which had a couple of initial difficulties (but did well afterwards). At least no-one crashed!

Segway introduction
Segway introduction by a professional -- my take away: The "bootie stop", the quickest way to get your Segway halted.

Later the day, we got to see the good old Golden Gate bridge. And a couple of students took the opportunity to walk the 2.7 km bridge by foot. Crazy youngsters.

Ilya, Sergey and me at the Golden Gate bridge
Ilya, Sergey and me being strong at the selfie game

We were also lucky to see a couple of humpback whales popping up directly under the bridge this day, amazing!

Pictures of humpback whales under the Golden Gate bridge
Humpback whales under the Golden Gate bridge (Picture courtesy: Jack Pan-Chen -- great shot!)

We concluded the end of day with a pretty scenic cruise from Sausalito (the city right next to other side of the Golden Gate bridge) back to SF harbor.

More food and drinks included (yes, Google was trying hard cramming us).

Day 4: More talks, end of the summit

Day marked the end of the whole summit, with a couple more talks from Google engineers -- mentors and students both got the opportunity to talk a bit about whatever they wanted, too.

View from Google SF office
View from Google SF office at the San Francisco–Oakland Bay Bridge

The remaining talks were about the new Google Open Source web page and how Open Source software is managed at Google (hint: every repository is mirrored internally, otherwise wouldn't be manageable). Next was a talk about Kubernetes, Google's container orchestration software, and an introduction to Code Jam, a competitive programming contest hosted by Google on a yearly basis.
The talk about Project Fi, a multi-carrier "wireless" service provider, was super insightful after all. It's fascinating to see the challenges phone operating systems are facing when trying to do clever real-time network/carrier switching on-the-go, and how Project Fi tries to do better by improving the SIM card design at the lowest levels.
Last but not least, one of the Googlers gave us an introduction to LLVM at Google, and how they switched from GCC to Clang internally a while ago, and that they're actually working a lot on performance improvements in the LLVM stack these days.


I'd like to take the opportunity to thank KDE for letting me attend this summit in the first place. Lots of thanks go out to the hard-working GSoC/GCI admins in KDE, namely Valorie Zimmermann and Bhushan Shah, who keep that whole thing running and nag people when deadlines are close!

Also lots of thanks to Google for sponsoring these kind of programs and for inviting people to their premises for gathering together. Thanks a lot to Stephanie, Mary, Cat, Helen, Josh (all Googlers) for their hard work keeping the attendants happy during the whole four days!

Icemon 3.1.0 release

More than one year after the 3.0.1 release, here's a new minor release of Icemon: 3.1.0.

Lots of bug fixes and small code refactorings, but also a few feature additions made it into this release.

Here's the changelog for the 3.1.0 release:


- Summary view: Multiple improvements (#23)
    - Displays average time for each submitted jobs
    - Added display of average build time for finished jobs
- Added scheduler hostname option (#27)


- Fixed summary view stateWidget color not updated correctly (#23)
- ListView: Sorted file sizes correctly (643abfbbdeed806aa5a08f0c1cfcdaf7ba79d748)
- Fixed filtering in detailed host view (#26)

Internal Changes:

- Lots of cleanups, more strict compiler flags, etc.

Get it:

$ git clone 
$ git checkout v3.1.0


Q&A session: To all those using Kate for hacking on C++ -- Why don't you try KDevelop?

Let's start with some luridness:

Now from the beginning: I got to know quite a few people in the past decade (phew, I'm such a dinosaur!) who use Kate as their editor of choice to hack on C++ code, on a daily basis. While I totally agree Kate is an excellent editor -- don't get me wrong on that, I use it literally every day, too -- it doesn't and can't possibly provide the best experience when working with C++ code, in my book. This is not about Kate vs. KDevelop -- not at all. This is about a text editor vs. an integrated development environment for C++.

If you're working with QtCreator, Eclipse, Visual Studio, whatever, that's totally fine -- all those are decent IDEs you can use to work with C++, all those have immense set of features which help you get along while hacking.

They key thing me as a KDevelop developer fails to understand is:

Why would you want to use the Kate text editor to hack on C++, if the exact same text editor component is inside KDevelop; a fully-featured C++ IDE!

Just recently I've learned from another KDE community member that he (citing him here) doesn't seem to need any of the things KDevelop has over Kate. Unfortunately I've heard that a few times now, so I think we as the KDevelop team are just pretty pretty bad at marketing the capabilities of KDevelop or KDevelop just sucks.

In good faith I'm presuming the former, since we actually got plenty of cheerful reviews on social media sites (reddit, blog post comments, you name it) about the new KDevelop 5 release, featuring the new C++ support backed by Clang/LLVM. Let me show you a quick overview over how KDevelop 5 looks like, what it has to offer and how code browsing looks like.

Quick KDevelop feature tour:

Of course there are a lot more features (e.g. unit test runner, patch review, VCS integration, debugger integration, code refactoring utils, etc. pp.), but this was the best I could come up with my half-baked screencasting skills in a rush. Check out the Feature Tour on the KDevelop website for more information.

I'd love to get some input from this particular set of users who use Kate as their main C++ IDE (I'm not talking about users who occasionally edit some .cpp file in an editor, I'm referring to power users who work with Kate on C++ on a daily basis):

  • Did you ever try KDevelop? What did you not like?
  • What made you switch back to Kate?
  • What does Kate offer what KDevelop does not?
  • Under what scenarios would you consider switching to KDevelop?

Please enlighten me! :)

PS: If you didn't know yet: You literally need to type in three commands into your shell to get KDevelop on your distro via our AppImage.

PPS: I hope you're aware I'm just mocking you here, you're of course free to use whatever tool you like to use. I'd just like to get some data points where we (as the KDevelop team) can improve in future to provide a better hacking on C++ experience!

KDevelop: Seeking maintainer for Ruby language support


just a short heads-up that KDevelop is seeking for a new maintainer for the Ruby language support. Miquel Sabaté did an amazing job maintaining the plugin in the recent years, but would like to step down as maintainer because he's lacking time to continue looking after it.

Here's an excerpt from a mail Miquel kindly provided, to make it easier for newcomers to follow-up on his work in kdev-ruby:

As you might know the development of kdev-ruby has stalled and the KDevelop team is looking for developers that want to work with it. The plugin is still considered
experimental and that's because there is still plenty of work to be done. What has been
done so far:

  • The parser is based on the one that can be found on MRI. That being said, it's based on an old version of it so you might want to update it.
  • The DUChain code is mostly done but it's not stable yet, so there's quite some work to be done on this front too.
  • Code completion mostly works but it's quite basic.
  • Ruby on Rails navigation is done and works.

There is a lot of work to be done and I'm honestly skeptical whether this approach will end up working anyways. Because of this skepticism and the fact that I was using another editor, I ended up abandoning the project and thus kdev-ruby was no longer maintained by anyone.

If you feel that you can take the challenge and you want to contribute to kdev-ruby, please reach out to the KDevelop team. They are extremely friendly and will guide you on the process of developing this plugin.

Again, thanks for all your work Miquel, you will be missed!

If you're interested in that kind of KDevelop plugin development, please get in touch with us!

More information about kdev-ruby here:

KDevelop for Windows available on Chocolatey now

You might have noticed there's KDevelop for Windows out now...

Which is already great in itself! But now it's also possible to install it via the super popular Windows package manager for Windows, Chocolatey.

Here's all you need (in case you already have Chocolatey installed on your system):

  • Start a Command Prompt as Administrator user
  • Type in choco install kdevelop to install
  • Start KDevelop via the Windows start menu

That's it!

Note: KDevelop does not ship a C++ compiler, you'll need to either setup MinGW/GCC, Microsoft VC++ or even Clang on Windows. Setup instructions here:

Here's what choco it does:

C:\WINDOWS\system32>choco install kdevelop  
Installing the following packages:  
By installing you accept licenses for the packages.

kdevelop v5.0.2 [Approved]  
Downloading kdevelop 64 bit  
  from ''
Progress: 100% - Saving 90.45 MB of 90.49 MB (94839304/94887333)  
Download of kdevelop-5.0.2-x64-setup.exe (90.49 MB) completed.  
Hashes match.  
Installing kdevelop...  
kdevelop has been installed.  
Added C:\ProgramData\chocolatey\bin\kdevelop.exe shim pointed to 'c:\program files\kdevelop\bin\kdevelop.exe'.  
 The install of kdevelop was successful.
  Software installed as 'EXE', install location is likely default.

Chocolatey installed 1/1 packages. 0 packages failed.  
 See the log for details (C:\ProgramData\chocolatey\logs\chocolatey.log).

Check out Pro / Business for more features!

C:\WINDOWS\system32>where kdevelop  

Happy hacking!

Thanks a lot to Hannah von Reth for setting up the KDE Chocolatey category, including publishing the KDevelop package there!

As always, we ask you to provide us with any kind of feedback on the Windows version! It's much appreciated.

What's new in KDevelop 5.0?

Almost two years after the release of KDevelop 4.7, we are happy to announce the immediate availability of KDevelop 5.0!

Screenshot showing KDevelop 5.0 under Linux

While the release announcement on is kept short intentionally, this blog post is going more into depth, showing what's new in KDevelop 5.0.

Read on...

Changes in language support

C++ support powered by Clang

We replaced our legacy C++ parser and semantic analysis plugin with a much more powerful one that is based on Clang from the LLVM project.

A little bit of history: KDevelop always prided itself for its state of the art C++ language support. We introduced innovative code browsing functionality, semantic highlighting and advanced code completion, features that our user base has come to rely upon for their daily work. All of this was made possible by a custom C++ parser, and an extremely complex semantic analyzer for the C++ language. Adding support for all the quirky corner cases in C++, as well as maintaining compatibility with the latest C++ language standards such as C++11, drained our energy and stole time needed to improve other areas of our IDE. Furthermore, the code was so brittle, that it was close to impossible to improve its performance or add bigger new features such as proper C language support.

Now, after close to two years of work, we finally have a solution to this dilemma: A Clang based language plugin. Not only does this give us support for the the very latest C++ language standard, it also enables true C and Objective-C language support. Furthermore, you get all of the immensely useful compiler warnings directly inside your editor. Even better, fixing these warnings is now often just a matter of pressing a single button to apply a Clang provided fix-it!

Screenshot of KDevelop showing Clang fixits

There are, however, a few caveats that need to be mentioned:

  • On older machines the performance may be worse than with our legacy C++ support. But the new Clang based plugin finally scales properly with the number of cores on your CPU, which can lead to significantly improved performance on more modern machines.
  • Some features of our legacy C++ support have not yet been ported to the new plugin. This includes special support for Qt code, most notably signal/slot code completion using the old Qt 4 macro syntax. We will be working on improving this situation and welcome feedback from our users on what we should focus on.
  • The plugin works fine with Clang 3.6 and above, but some features, such as auto-type resolution in the code browser, or argument code completion hints within a function call, require newer versionsof Clang. The required changes have been contributed upstream by members of our community and we intend on continuing this effort.

Another screenshot to make you want to try KDevelop 5.0 instantly:

Screenshot of KDevelop analyzing doxygen-style code comments (KDevelop analyzing doxygen-style code comments)

For the best C++ experience in KDevelop, we recommend at least Clang 3.8.

CMake support

We removed the hand-written CMake interpreter and now leverage meta data provided by upstream CMake itself. The technology we're building upon is a so called JSON compilation database (read more about it in this insightful blog post). Technically, all you need to do is to run cmake with the -DCMAKE_EXPORT_COMPILE_COMMANDS flag, and CMake will take it from there, emitting a compile_commands.json file into your build directory.

KDevelop now supports reading those files, which is way more reliable than parsing CMake code ourselves.

But this step also means that we had to remove some of the useful advanced CMake integration features, such as the wizards to add files to a target. We are aware of this situation, and plan to work together with upstream to bring back the removed functionality in the future. Hopefully, you agree that correctness and much improved performance, where opening even large CMake projects is now close to instant, makes up for the loss of functionality.

QML/JavaScript support

With KDevelop 5, we decided to officially include support for QML and JavaScript code. This functionality has been worked on for years in our playground and now, we finally incorporated these experimental plugins and will start to officially support them.

Screenshot showing KDevelop's QML support

Our thanks go to the Qt Creator community here, as we leverage their QML and JavaScript parser (QmlJS, see here) for our language support plugin.

Screenshot showing KDevelop's QML support

QMake support

With KDevelop 5, we decided to officially include support QMake projects, too. Same story here, this functionality has been worked on for years and we now start to officially support them.

The new KDevelop plugin for QMake is simplistic but already super useful for many projects. If you are using more complicated QMake features and want to improve our interpreter, please get in touch with us!

Python, PHP, ...

Together with all this, KDevelop 5 will continue to officially support Python 3 and PHP. In our playground we also have support for Ruby, and there are plans to integrate basic Go and Rust support. If you are interested in improving support for any of these languages in KDevelop, please step up and start contributing!

Screenshot of KDevelop's Python support

Other changes

Remove assistant overlay in favor of navigation widget

Another major thing we worked on was rethinking KDevelop’s assistant popup; especially in the current 5.0 betas, it tended to be a bit annoying and got in the way a lot. We thus removed the assistant overlay in favor of offering executions of assistants from the navigation widget.

Here's a screenshot of the assistants in form of a navigation widget:

Screenshot of KDevelop's new assistant widget

Key changes:

  • No longer automatically popup a widget whenever there's a problem (distracting!)
  • Only popup when invoked (via Alt, or via mouse hover)
  • Show problems on keyboard activation (via Alt, wasn't possible before)
  • We can use more text in the solution assistant descriptions (since we requested them, we can cover more space implicitly)
  • No longer creates a OpenGL context each time there's an error (this has been slow at times, using the old assistant popup. There was a noticable lag while typing on heavy load)

Per-project widget coloring

Thanks to Sebastien Speierer we got a super useful feature into KDevelop 5.0: Widget coloring based on an items affinity to a project.

A picture is worth more than a thousand words, see it in action here:

Screenshot showing KDevelop's per project widget coloring

As you can see, both the project explorer rows as well as the document tab bar items are colored based on the project affinity. This is useful to quickly decide which project a specific file belongs to.

(Note this feature is optional, it's possible to enable/disable in settings)

Progress reporting of make/ninja jobs

We added support for tracking the progress of make/ninja jobs in KDevelop, we do so by simply parsing the first few chars of the output of make and ninja. For make, this will only work for Makefiles generated by CMake so far, as those contain proper progress information). Thus, this feature won't work when make is invoked on Makefiles generated by QMake.


Screenshot showing KDevelop reporting ninja's progress

The progress bar on the bottom right indicates the progress of the ninja invokation. Extra gimmick: Starting with Plasma 5.6, this progress is also indicated in the task bar entry of your task switcher in the Plasma shell.

Welcome Page redesign

The welcome page (the widget which is shown whenever you have no tabs open in KDevelop) got redesigned to better match the current widget style in use). Screenshot:

Screenshot of KDevelop's welcome page plugin

Various debugger related improvements

Debugger support is KDevelop's unloved child, but it got some improvements in 5.0, and will get quite a few improvements in the upcoming 5.1 release (due to the LLDB GSoC happening, which also touches lots of debugger agnostic code).

Debugger support in 5.0 was improved by simply streamlining the debugger related widgets where possible.

Screenshot of KDevelop's frame stack tool view


  • Frame stack model: Non-existing files are now rendered in gray
  • Frame stack model: Pretty urls for file paths (i.e. myproject:src/main.cpp), elided in the middle now
  • The crashed thread is now highlighted properly
  • A lot more

Splash screen removal

For performance reasons the splash screen got removed in 5.0. There's been a short discussion on the KDevelop development mailing list about the pros and cons, in the end we decided to drop it.

The reasons for dropping it were:

  • Perfomance: Our QML-based splash screen actually had a noticeable impact on the start time of KDevelop (kind of defeated its purpose)
  • Feels old-fashioned: Showing a splash screen always makes me feel a bit nostalgic, it's just not a modern way to indicate that your application is starting up. All modern DEs provide a way to indicate this (i.e. by a bouncy cursor in Plasma, good old hourglass in Windows -- and OS X has animations for this as well).
  • Startup time got improved significantly (see more about that below) during 4.x -> 5.x, so it no longer felt necessary

Under the hood

Just an excerpt:

  • We have ported our huge code base to Qt 5 and KDE frameworks 5 (KF5).
  • We cleaned up many areas of our code base and improved the performance of some work flows significantly.
  • (Cold) start performance of KDevelop got improved significantly due to changes in KDevelop and libraries below (KF5 icon loading, KF5 plugin loading, etc.) -- something in the order of several seconds on my test machine (Lenovo T450s).

Just to get you an idea how much work was put into the 5.0 release over the years:

kdevplatform% git diff --stat origin/1.7 v5.0.0 | tail -n1  
 1928 files changed, 65668 insertions(+), 73882 deletions(-)

kdevelop% git diff --stat origin/4.7 v5.0.0 | tail -n1  
 1573 files changed, 131850 insertions(+), 30347 deletions(-)

Get it

Linux AppImage

If you're on Linux you can start using KDevelop right away, by downloading & running the new KDevelop 5.0 AppImage.

Other platforms

With KF5 overall cross-platform support of KDE applications got better by order of magnitudes. Tons of hours have been spent improving OS X and Windows support.

We hope to release an official OS X app bundle & a Windows installer package soon.

Edit (Oct 2016): We now have a Windows version available!

Read more about other installation instructions.


We're super proud to finally release KDevelop 5.0 to the public! We think it's a solid foundation for future releases.

With the use of Clang as the C++ support backend we hope to be able to put more energy into the IDE itself as well as other plugins instead of playing catchup with the C++ standard!

Happy to hear your opinions about KDevelop 5.0. What do you like/dislike?

KDE on Windows status update

Disclaimer: No, it's not dead :)

During Randa we've discussed the KDE on Windows road map. There's been a brisk involvement of the Randa Meetings participants in the platform discussion sessions on Tuesday.

Here's a brief summary of what's been going on.

Installer creation

Traditionally the KDE on Windows project has been focused on providing one single installler which provides the whole KDE experience in one installer (that means, having one installer which was capable of installing all of KDE, even including the Plasma shell). We've (finally?) come to conclusion this is not what the average Windows users wants. People tend to install the application they want, but nothing else.

Our plan now is to provide single application installers for KDE software. That means having an installer which just installs Kate, or Krita, or KDevelop, or Marble, whatever. No "KDE installer" where you can select the individual applications.

We're just at the beginning of the initiative (with lots of bug fixing going on behind the scenes), but here's the current list of applications being available on Windows:

Hannah von Reth is working hard on creating even more installer packages!

Continuous Integration on Windows

We're working on Windows CI for KDE. More precisely, that means we're turning the original KDE CI infrastructure into a system where we can also build the KDE projects on Windows. This is all work in progress, but we expect to have the first set of jobs running on our sandbox CI system running until the end of the week.

Up to now, our plan is to reuse the existing Emerge infrastructure for CI as much as possible, which also covers building all the dependencies of Qt5.


Emerge is a tool to build the KDE sources and its third-party requirements on MS Windows. Traditionally. It's way more than that today: With Emerge it's possible to build any project if you just provide a recipe for it, highly similar to comparable tools such as Homebrew on OS X. If you have a complex dependency chain, and need a user space package manager (which builds from source), then Emerge is the tool to use.

During Randa we have polished the OS X and Linux ports of emerge, making it super easy to build projects including all its dependencies even on those platforms. The support is not official yet, it's still work in progress. We'll officially announce as soon as this gets ready. Just one example: we've successfully built Kate on OS X using Emerge with a stock Qt5.

What else has changed in Emerge:

  • Almost all custom Qt patches could be dropped in emerge.git
    • Most of the missing functionality is now upstream
  • Qt 5.6.1 used by default in the Qt recipes
  • Breeze-icons recipe now installs icons as RCC (see David Faure's blog for more information about this feature)
  • Emerge prepared for being integrated as build tool in the Windows CI
    • Now possible to install dependencies, store build artifacts in zip files, etc.
    • Build artifacts can be re-used for other builds

Landing page

We've also cleaned up the KDE on Windows landing page a lot:

Tons of information the average user isn't interested in got removed or moved to sub pages.


KDE on Windows is not dead, as some people from the outside tend to think. It's true we're no longer willing to maintain a "KDE installer" as such, but instead focus on bringing individual apps which are ready on Windows to this platform.

Keep your eye on to get notified about new packages.

Actually, a big thank goes to Hannah von Reth, who's the actual maintainer of Emerge, who does a great job bringing this super useful tool forward and does a great job fixing tons of Windows issues in KDE projects.

Apart from that: Which favorite KDE application would you like to install yourself on Windows?

Support us

The Randa Meetings and other sprints indeed bring our software stack forward! Nowhere else such a nice group of KDE developers can meet up to solve such problems together! Please check out the fundraiser for the ongoing Randa Meetings.