Almost two years after the release of KDevelop 4.7, we are happy to announce the immediate availability of KDevelop 5.0!
While the release announcement on kdevelop.org is kept short intentionally, this blog post is going more into depth, showing what's new in KDevelop 5.0.
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!
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:
(KDevelop analyzing doxygen-style code comments)
For the best C++ experience in KDevelop, we recommend at least Clang 3.8.
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.
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!
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:
- 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:
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.
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:
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.
- 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(-)
If you're on Linux you can start using KDevelop right away, by downloading & running the new KDevelop 5.0 AppImage.
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?