25 Aug 2016

feedPlanet KDE

KDevelop, Muon, Plasma 5.7.4

To celebrate the release of KDevelop 5 we've added KDevelop 5 to KDE neon User Edition. Git Stable and Git Unstable builds are also in the relevant Developer Editions.

But wait.. that's not all.. the package manager Muon seem to have a new maintainer so to celebrate we added builds in User Edition and Git Unstable Developer Edition.

Plasma 5.7.4 has been out for some time now so it's well past time to get it into Neon, delayed by a move in infrastructure which caused the entire repository to rebuild. All Plasma packages should be updated now in KDE neon User Edition.

Want to install it? The weekly User Edition ISO has been updated and looks lovely.

Facebooktwittergoogle_pluslinkedinby feather

25 Aug 2016 3:30pm GMT

Mobile IMG – 20160825-142223

There is new mobile IMG update, this brings,

You can flash using instructions at https://plasma-mobile.org/nexus-5/

25 Aug 2016 3:03pm GMT

Panels on shared screen edges

Plasma 5.8 will bring an improvement fixing a bug reported more than a decade ago. Back then Plasma did not even exist, the bug is reported against an early KDE 3 version. The addressed problem is the handling of panels on multi-screen setups.

This is if one has multiple screens and tries to put a panel between two screens - on the shared edge - the panel does not have a "strut" set and thus windows maximize below it:

|            ||P           |
|      1     ||P     2     |
|            ||P           |

In this illustrated setup the panel is "P" and windows on screen 2 ignore the panel. What might be surprising here is that this was not just a bug, but deliberate behavior. There is code making sure that the panel on the shared edge gets ignored. Now one doesn't write code to explicit break useful features, there's obviously a good reason for that.

And to understand that we must look at how panels and there struts work. First let's look at Wayland. Wayland doesn't have a concept for panels or struts by default. KWin provides the PlasmaSurface interface which Plasma can use to give a window the role "Panel" and to describe how the panel is used: whether it's always on top, or whether windows can cover it or go below. KWin can use that to decide whether the panel should have a strut or not. Thus on Wayland KWin was able to support the setup shown above since it supports panels.

On X11, though, we have the NETWM spec which describes how to set a partial strut:

The purpose of struts is to reserve space at the borders of the desktop. This is very useful for a docking area, a taskbar or a panel, for instance. The Window Manager should take this reserved area into account when constraining window positions - maximized windows, for example, should not cover that area.

The start and end values associated with each strut allow areas to be reserved which do not span the entire width or height of the screen. Struts MUST be specified in root window coordinates, that is, they are not relative to the edges of any view port or Xinerama monitor.

Now here we see already the problem: it's not multi screen aware. The strut is specified in root window coordinates. So in our case above we would need to set a strut for the left edge which spans the complete height. So far so good. But the width of the strut must be specified in root window coordinates which includes the complete screen 1. If Plasma would set this, we would have a problem.

In Plasma 5.7 KWin's strut handling code got slightly reworked to perform sanity checks on the struts and to ignore struts affecting other screens. Basically KWin broke the implementation of given spec and in multi-screen setups only allows struts which make sense.

Now at least KWin could handle this situation properly, but Plasma still has the check to not set a strut on shared edges. For Plasma 5.8 we now changed the condition: if the window manager is KWin we allow such struts. For any other window manager we still go with the previous solution. We still think that we cannot just set a strut which would in the worst case exclude a complete screen. As that's how the spec is written, we need to assume the window manager is standard compliant. For KWin we know that it is not standard compliant any more and support such struts, so Plasma can make use of it.

This change hopefully improves the multi-screen experience for our Plasma users who use KWin as a window manager.

25 Aug 2016 2:30pm GMT

Latest attacks on privacy...

With the EU (in this case France and Germany) gearing up for another attack on privacy I'm quite happy and proud to have been part of the release of Nextcloud 10!


It is the usual story: we should disallow companies from using perfect end to end encryption and force them to insert backdoors against terrorists.

Not that it would help - that's been discussed extensively already but in short:
  • If you have nothing to hide, you'll use a backdoored app and you're vulnerable to foreign (and your own) governments, terrorists (!), criminals and others who can abuse your data in more ways than you can imagine.
  • If you have something to hide, you can use 1000 different tools to do so and there is nothing government can do about that so you won't use a backdoored app.
  • And note that government has failed to even use fully unencrypted information to stop terrorist attacks so perhaps we should first see if they can actually get their act together there.
Now yes, backdooring all commonly used encryption apps will help a BIT, essentially only with the low level, common crime. So you might catch the dude who broke into your house and bragged about it to his friends over Whatsapp. You won't catch the terrorists plotting with Al Qaida (or whatever the terrorist organization du-jour) to blow up a train because they can simply get one of the many solutions out there to protect themselves.

Nor will you catch corrupt politicians or big companies doing nasty stuff, though I am quite certain the laws will be written in such a way that you can use them to go after people who actually try to expose such politicians or companies.

And I'm also quite certain companies will use this as an excuse to not implement proper protection in their products so you can continue to stop pacemakers remotely or disable the brakes in cars over the internet.

Generally, laws targeting encryption and terrorism do more to harm whistleblowing than terrorism and are thus promoting corruption and bad, unsecure products.

These laws will literally cost lives. Not save any.

And it is exactly why Frank started ownCloud and why we continue to develop that vision at Nextcloud. And keep developing new features, like the File Access Control app which can provide an extra protective layer around your data. I for one certainly can use that app and exactly in the way described in that blog! So much for 'enterprise only features'.

Get it and migrate today. You and your data deserve it!

25 Aug 2016 11:21am GMT

24 Aug 2016

feedPlanet KDE

Wiki, what’s going on? (Part 8-Akademy2016)


Hello everybody,

It's august and probably you are on holiday, life seems beautiful and you hope this period never ends, but… Happy or not September is about to arrive, and your daily routine is too. Don't be afraid though: in these months the WikiToLearn community is working hard to provide you the best WikiToLearn you've seen so far.

From a brand new homepage to a better organization for news and social pages: you're going to love it! September is not that sad though: why? If the new WikiToLearn isn't enough for you, probably Akademy is: the annual word summit of KDE, this year happening in Berlin with QtCon, is one of the greates events for FOSS and we are taking part to it! Why is it so special for us? First of all because we're part of the KDE community and we are looking forward to meet other members, share opinions and help each other, but also because this period is going to be special: KDE has its 20th birthday while Free Software Foundation Europe and VideoLAN both have their 15th birthday. Not over yet: you know who's celebrating its birthday too in the same period? WikiToLearn! 😀

During these months we worked hard to create local communities, to spread the word about our project, to give more attention and help to new users and to come up with a better communication plan that allows you to be always up to date on what's going on in our community. September is not that far and it's full of great news, get ready and prepare yourself!

Watch out: #wtlatakademy #wtlbirthday and others can become viral on our social pages in few weeks, we're going to Akademy! 😉



L'articolo Wiki, what's going on? (Part 8-Akademy2016) sembra essere il primo su Blogs from WikiToLearn.

24 Aug 2016 5:19pm GMT

Going to Akademy

I'm going to Akademy! Akademy 2016, as part of QtCon, that is. I missed last year in A Coruña because it conflicted with my family summer vacation, but this year is just fine (although if I was a university student I'd be annoyed that Akademy was smack-dab in the middle of the first week of classes - you can't please everyone).

Two purely social things I will be doing are baking cookies and telling stories about dinosaurs. I have a nice long train ride to Berlin to think of those stories. But, as those of you who have been following my BSD posts know, the dinosaurs are not so backwards anymore. Qt 5.6 is doing an exp-run on FreeBSD, so it will be in the tree Real Soon Now ™, and the Frameworks are lined up, etc. etc. For folks following the plasma5 branch in area51 this is all old hat; that tends to follow the release of new KDE software - be it Frameworks, or Plasma, or Applications, or KDevelop - by a few days. The exciting thing is having this all in the official ports tree, which means that it becomes more accessible to downstreams as well.

Er .. yeah, dinosaurs. Technically, I'm looking forward to talking about Qt on BSD and KDE Plasma desktop and other technologies on BSD, and about the long-term effects of this year's Randa meeting. I have it on good authority that KDE Emerge^WRunda^W KDE Cauldron is being investigated for the BSDs as well.

24 Aug 2016 1:27pm GMT

Multiscreen in Plasma: Improved tools and debugging

Plasma 5.8 will be our first long-term supported release in the Plasma 5 series. We want to make this a release as polished and stable as possible. One area we weren't quite happy with was our multi-screen user experience. While it works quite well for most of our users, there were a number of problems which made our multi-screen support sub-par.
Let's take a step back to define what we're talking about.

Multi-screen support means that connecting more than one screen to your computer. The following use cases give good examples of the scope:

The idea is that the user plugs in or starts up with that configuration, if the user has already configured this hardware combination, this setup is restored. Otherwise, a reasonable guess is done to put the user to a good starting point to fine-tune the setup.

This is the job of KScreen. At a technical level, kscreen consists of three parts:

At an architectural level, this is a sound design: the roles are clearly separated, the low-level bits are suitably abstracted to allow re-use of code, the API presents what matters to the user, implementation details are hidden. Most importantly, aside from a few bugs, it works as expected, and in principle, there's no reason why it shouldn't.

So much for the theory. In reality, we're dealing with a huge amount of complexity. There are hardware events such as suspending, waking up with different configurations, the laptop's lid may be closed or opened (and when that's done, we don't even get an event that it closed, displays come and go, depending on their connection, the same piece of hardware might support completely different resolutions, hardware comes with broken EDID information, display connectors come and go, so do display controllers (crtcs); and on top of all that: the only way we get to know what actually works in reality for the user is the "throw stuff against the wall and observe what sticks" tactic.

This is the fabric of nightmares. Since I prefer to not sleep, but hack at night, I seemed to be the right person to send into this battle. (Coincidentally, I was also "crowned" kscreen maintainer a few months ago, but let's stick to drama here.)

So, anyway, as I already mentioned in an earlier blog entry, we had some problems restoring configurations. In certain situations, displays weren't enabled or positioned unreliably, or kscreen failed to restore configurations altogether, making it "forget" settings.

Better tools

Debugging these issues is not entirely trivial. We need to figure out at which level they happen (for example in our xrandr implementation, in other parts of the library, or in the daemon. We also need to figure out what happens exactly, and when it does. A complex architecture like this brings a number of synchronization problems with it, and these are hard to debug when you have to figure out what exactly goes on across log files. In Plasma 5.8, kscreen will log its activity into one consolidated, categorized and time-stamped log. This rather simple change has already been a huge help in getting to know what's really going on, and it has helped us identify a number of problems.

A tool which I've been working on is kscreen-doctor. On the one hand, I needed a debugging helper tool that can give system information useful for debugging. Perhaps more importantly I know I'd be missing a command-line tool to futz around with screen configurations from the command-line or from scripts as Wayland arrives. kscreen-doctor allows to change the screen configuration at runtime, like this:

Disable the hdmi output, enable the laptop panel and set it to a specific mode
$ kscreen-doctor output.HDMI-2.disable output.eDP-1.mode.1 output.eDP-1.enable

Position the hdmi monitor on the right of the laptop panel
$ kscreen-doctor output.HDMI-2.position.0,1280 output.eDP-1.position.0,0

Please note that kscreen-doctor is quite experimental. It's a tool that allows to shoot yourself in the foot, so user discretion is advised. If you break things, you get to keep the pieces. I'd like to develop this into a more stable tool in kscreen, but for now: don't complain if it doesn't work or eat your hamster.

Another neat testing tool is Wayland. The video wall configuration you see in the screenshot is unfortunately not real hardware I have around here. What I've done instead is run a Wayland server with these "virtual displays" connected, which in turn allowed me to reproduce a configuration issue. I'll spare you the details of what exactly went wrong, but this kind of tricks allows us to reproduce problems with much more hardware than I ever want or need in my office. It doesn't stop there, I've added this hardware configuration to our unit-testing suite, so we can make sure that this case is covered and working in the future.

24 Aug 2016 1:16pm GMT

SSH and complex configs


Today I want to talk about the .ssh/config file, for who don't knows about it is the configuration file for SSH to customize options to connect with SSH.

The issue with this file is: it don't supports some kind of "include", this can be an issue if you have to write long config file.

I wrote a bit of shell script to workaround this (you can see the script here https://quickgit.kde.org/?p=scratch%2Ftomaluca%2Fssh-build-config.git).

This script creates the .ssh/config reading slice of config from .ssh/config.d/ in order and recursively.

I hope to be helpfull for someone.

24 Aug 2016 6:58am GMT

23 Aug 2016

feedPlanet KDE

Try this handy tool to convert a Web site into a native app with Electron

The Electron framework lets you write cross-platform desktop applications using JavaScript, HTML and CSS. It is based on Node.js and Chromium and is used by the Atom editor and many other apps.

There is an handy tool to take advantage of Electron technology and make "native" apps from an URL, Nativefier:

npm install nativefier -g
nativefier "https://example.com"

(you just need npm package manager to install it)

It will make a folder in your Home with the executable in it:

how Nativefier works

This is how Google+ looks for example:


Zero differences compared to Chrome/Chromium web app apparently, but the RAM used is much lower:

You also get a better integration with the desktop enviroment, for example clicking on a link open the default browser, not necessarily Chrome/Chromium, and native notifications:

Native notification with Electron

And my favorite feature, CSS and JavaScript injection: you can specify some CSS/JavaScript code to include before building the app with --inject.

For example I used some CSS rules to add a Breeze style to Diaspora*:

Diaspora* with Breeze style

I'm going to build more apps. Ciao!

23 Aug 2016 9:13pm GMT

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 kdevelop.org 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:

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:

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


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:

Under the hood

Just an excerpt:

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.

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?

23 Aug 2016 6:15pm GMT

KDevelop 5.0.0 release

KDevelop 5.0.0 release

Almost two years after the release of KDevelop 4.7, we are happy to announce the immediate availability of KDevelop 5.0. KDevelop is an integrated development environment focusing on support of the C++, Python, PHP and JavaScript/QML programming languages. Many important changes and refactorings were done for version 5.0, ensuring that KDevelop remains maintainable and easy to extend and improve over the next years. Highlights include much improved new C/C++ language support, as well as polishing for Python, PHP and QML/JS.

This release announcement is kept short intentionally, to check out what's new in KDevelop 5.0, please read this blog post by Kevin.

KDevelop 5.0 screenshot

C/C++ language supported now backed by Clang

The most prominent change certainly is the move away from our own, custom C++ analysis engine. Instead, C and C++ code analysis is now performed by clang. Aside from being much easier to maintain, this has a number of advantages:

  • Even the most complex C++ code constructs are now parsed and highlighted correctly and reliably. In the end there's a compiler in the background -- KDevelop will complain exactly if it wouldn't compile.
  • Diagnostics are a lot more accurate and reliable. For example, KDevelop can now detect whether or not there is an overload of a function available with the parameters you are passing in.
  • For many problems (e.g. misspelled variable names, missing parentheses, missing semicolon, ...), we get suggestions on how to correct the problem from clang, and offer the user a shortcut key (Alt+1) to apply the fix automatically.
  • There is now a C parsing mode, which enables the analysis engine to correctly parse C code.

Work on getting all our old utilities for C++ to work nicely with the new infrastructure is still ongoing in some areas, but most of the important things are already in place. In contrast to the C++ support, the Python support has not undergone any significant refactoring, but has instead seen further stabilization and polishing. The same is true for the PHP and QML/JS language support components.

Qt 5, KDE Frameworks 5, and other platforms

Apart from those changes, KDevelop 5 has of course been ported to KDE Frameworks 5 and Qt 5. This will for the first time enable us to offer an experimental version of KDevelop for Microsoft Windows in the near future, in addition to support for Linux. Additionally, we offer experimental stand-alone Linux binaries, which make it much easier for you to try KDevelop 5 before upgrading your system-wide installation.


You can download the source code from here. The archives are signed with the following key ID: AC44AC6DB29779E6.

Along with KDevelop 5.0, we also release version 2.0 of the kdevelop-pg-qt parser generator utility; download it from here.

We also provide an experimental pre-built binary package which should run on any moderately recent linux distribution: Download AppImage binary for Linux (any distribution). After downloading the file, just make it executable and run it.

Update: We updated the AppImage (the new version is 5.0.0-1) and fixed a few issues with the packaging, esp. file and project templates not working. It also comes with kdev-php and the console toolview now.

Thanks to everyone involved in preparing the release!

kfunk Tue, 08/23/2016 - 20:00




Submitted by Musikolo (not verified) on Wed, 08/24/2016 - 05:24


I cannot wait more minutes for my distro to update KDevelop package to version 5.

As usual, you rock guys!


In reply to Superb! by Musikolo (not verified)

Submitted by kfunk on Wed, 08/24/2016 - 14:47

You could try the KDevelop 5…

You could try the KDevelop 5.0 AppImage right away! https://www.kdevelop.org/download


Submitted by Drizzt (not verified) on Wed, 08/24/2016 - 13:06

Perl support?

IIRC KDevelop had Perl support in the past but when I last checked the 4.x branch there was no integration of Perl. Is this something that'll be coming back? Because I'd really like to get rid of Eclipse and KDevelop is nice otherwise. But I do need Perl support.


In reply to Perl support? by Drizzt (not verified)

Submitted by Sven (not verified) on Wed, 08/24/2016 - 16:38

perl support

Nothing planned, sorry, and nobody involed with it at the moment uses perl. So unless somebody steps up, not likely to happen.


Submitted by Heller (not verified) on Wed, 08/24/2016 - 13:24

PHP plugin in AppImage ?

That's great, thank you to all involved people :) !
Any plan to support PHP in the AppImage (or I am missing something ?)


In reply to PHP plugin in AppImage ? by Heller (not verified)

Submitted by kfunk on Wed, 08/24/2016 - 14:48

Not yet, but it's on our…

Not yet, but it's on our TODO. Stay tuned.


In reply to PHP plugin in AppImage ? by Heller (not verified)

Submitted by Sven (not verified) on Wed, 08/24/2016 - 20:26

PHP plugin

It's in 5.0.0-1 which is up now, together with the konsole toolview and fixes for two issues with packaging. Let us know if it works for you.


In reply to PHP plugin by Sven (not verified)

Submitted by Heady (not verified) on Thu, 08/25/2016 - 16:28

Great work with the new…

Great work with the new release!

Here are some issues I have using the AppImage:
- qmake does not work because KDevelop tries to execute the build directory.
- importing or opening a cmake project throws the following error message:
"Could not load project management plugin KDevCMakeManager."

Keep up the good work!


In reply to Great work with the new… by Heady (not verified)

Submitted by scummos on Thu, 08/25/2016 - 20:43


Do you have cmake and qmake installed? The image doesn't ship with any dev tools, and the cmake plugin will only work if you actually have cmake.


Submitted by Alex (not verified) on Wed, 08/24/2016 - 21:53


What about TypeScript?


In reply to TS by Alex (not verified)

Submitted by Sven (not verified) on Wed, 08/24/2016 - 23:44

Re: TS

Patches welcome ;) Nobody around here uses that; JS support basically exists because QML uses JS. To support something like TypeScript, somebody from outside with experience and interest in the language would have to step up.


Submitted by Robbert (not verified) on Wed, 08/24/2016 - 22:45


Congratulations to all contributors involved in this major milestone, and thanks for all your efforts.

I'm trying the appimage now.


Submitted by vegorov (not verified) on Thu, 08/25/2016 - 08:59

Refactoring as you type?

I remember a feature from previous KDevelop 4.7 - you are typing over an existing symbol, popup message appears asking you if you want to refactor it, you press Alt-1 - voila, the symbol was rename-refactored. I can't find it in 5.0 anymore. Was it removed? It's a shame if it was. Ctrl-Shift-R rename refactoring uses a separate modal dialog, so there is no in-place refactoring at all.


In reply to Refactoring as you type? by vegorov (not verified)

Submitted by kfunk on Thu, 08/25/2016 - 13:31

Heya. …


It's a bit different in KDevelop 5.0, since we no longer provide those assistant popups as you know them. Try the following under KDevelop 5.0:

Rename a variable which is being used several times, wait for a few milliseconds. You'll notice the variable you just renamed gets a red underline (=> there's a problem). Hover it, you'll notice a solution to the problem, which is renaming all other uses. Clicking 'Solution (1)' will rename all uses.

The same is doable via keyboard shortcuts, too. After changing the variable, press and hold 'Alt' (you'll see the same popup as before), then press '1' to execute solution number one.

Hope that helps.

PS: There's a little bug we've not yet managed to fix: If you press and hold 'Alt' at the *end* of the variable name, the popup will not appear.

23 Aug 2016 6:00pm GMT

Krita 3.0.1 Beta Builds

We've made a new set of development builds in the road to Krita 3.0.1. Here are the most important bug fixes:

In other news, the Krita team will get together in Deventer, the Netherlands, this weekend to meet in person! We'll be fixing bugs, discussing and planning new features and plans for new training videos and more!


On Windows, Krita supports Wacom, Huion and Yiynova tablets, as well as the Surface Pro series of tablets. The portable zip file builds can be unzipped and run by double-clicking the krita link.

Krita on Windows is tested on Windows 7, Windows 8 and Windows 10. There is only a Windows 64 bits build for now. Also, there is debug build that together with the DrMingw debugger can help with finding the cause of crashes. See the new FAQ entry. The Windows builds can be slower than usual because vectorization is disabled.


For Linux, we offer AppImages that should run on any reasonable recent Linux distribution. You can download the appimage, make it executable and run it in place. No installation is needed. At this moment, we only have appimages for 64 bits versions of Linux. This appimage has experimental desktop integration.

You can also get Krita from Ubuntu's App Store in snap format. This version includes the translations for Krita itself. Install with

snap install --beta krita

OSX and MacOS

Krita on OSX will be fully supported with version 3.1. Krita 3.0 for OSX is still missing Instant Preview and High Quality Canvas scaling. There are also some issues with rendering the image - these issues follow from Apple's decision to drop support for the OpenGL 3.0 compatibility profile in their display drivers and issue with touchpad and tablet support. We are working to reimplement these features using OpenGL 3.0 Core profile. For now, we recommend disabling OpenGL when using Krita on OSX for production work. Krita for OSX runs on 10.9, 10.10, 10.11 and is reported to work on MacOS too.


23 Aug 2016 5:30pm GMT

Marble: GSoC 2016 wrap-up

Today is the deadline for submitting the final evaluations for Google Summer of Code 2016, that gives me the opportunity to write a wrap-up post about my project this summer.

About my project

The aim of my GSoC project this summer was to bring fluent rendering to Marble's OSM Vector Tile map theme. The idea for this map theme is to render the vector data taken from the openstreetmap and natural earth databases. These are merged and cut into many many tiles that are stored in .o5m format on a server, and downloaded by Marble. To achieve this in the frst place we needed a tool that will handle this for us. Creating that tool was my main objective.

osm-simplify tool

This little program's purpose is to generate the data used by the OSM Vector Tile map theme. It does many different things regarding map data manipulation, but one of it's most important job is to create the tiles. That means to cut a huge world map to tiny little tiles that can be rendered in Marble.
osm-simplify tool

The tool uses Marble's data handling and parsing which I demonstrated in my previous post. That way you can even use this tool as an example if you want to use Marble for your map data manipulation project, but this tool is far from just an example program.

Tile cutting

More exactly this turned out to be a very resource hungry program. If you look at this table, you can guess why is that:

The hardest part of the tile cutting algorithm was the processing of polygons. This turned out to be a little challenging, but in the end, the solution was to inject another algorithm into Marble's clipping algorithm. The Weiler-Atherton polygon clipping algorithm works on concave polygons too, that solves the borderline issue which I described in my previous post, that comes from the Sutherland-Hodgman polygon clipping algorithm. The tool now uses the more simple Sutherland-Hodgman algorithm for clipping non-polygons, and the Weiler-Atherton kicks in when dealing with polygons.

Here is a nice demonstration of the results of the osm-simplify tool. I loaded 20 separate map files, each is a level 5 tile generated with this tool. I marked the corners of the tiles with red, because they are generated without any gaps between them.

Turning on polygon debugging gives us a nice view of each tile and the underlying cutting process:

To be continued...

I've done a little benchmark to check the performance of the tool, and the results were not that promising. Just for zoom level 9 it needed 6 hours to generate all of the tiles from a single map. The good thing is, there is many ways to improve on the performance. Parallel processing and tile tessellation comes to help. That will be my autumn project, because in the end, Google Summer of Code is about to encouraging students to get involved with open-source projects.

Final words about GSoC 2016

This year I learned a lot about time management and programming, it was a really great experience. I don't know if I'll have time next year for GSoC, because that will be my last year in university, but I'll just encourage anyone who wants to participate in it, especially for KDE and the Marble team.

23 Aug 2016 5:15pm GMT

LabPlot: Theme Manager – GSoC’16 Final Evaluations

Hi folks!

GSoC'16 has come to an end and its time to report current status of my project 'LabPlot: Theme Manager'. As the name suggests, project was aimed to develop a theme manager for LabPlot, which is a well known open source application mainly used for analyzing and visualizing scientific data.

There have been a lot of developments after the project's mid-term evaluation period (previous results are discussed in my earlier blogs), as follows:


  1. Directly by clicking on the 'Apply theme' button available at the bottom of the Cartesian Plot dock widget (screenshot below)ApplyTheme01
  2. Through Cartesian Plot's context menu, by choosing 'Apply theme' option (screenshot below)ApplyTheme02

Final Result:

As a result, LabPlot is now equipped with a very well developed 'Theme Manager' providing a wide variety of 13 themes from basic to more advanced such as Solarized, SolarizedLight, DarkPastels, BlackOnWhite, BlueOnBlack, etc.(as mentioned above) and are also comparable to other existing applications. Currently, the Theme Manager has many useful functionalities such as application of themes on plots, saving personalized themes, uploading/downloading themes to share themes via web server (in progress). I believe current functionalities will make LabPlot a powerful tool to visualize scientific data as well as it will enrich the overall user experience and usability. Last but not the least, I am glad to say that I have successfully met all the proposed goals and deadlines as per my GSoC project proposal.

Overall Experience:

GSoc has been an amazing experience for me. As it was my first attempt at contributing to an open source project, I was amazed by the variety and quality of work carried out by the KDE community. Large number of developers and contributors working in parallel to produce interesting and extremely useful applications…It's really motivating!

I would also like to thank my mentor Alexander Semke, who has been very responsive and supportive throughout my journey of GSoC. Along with the technical skills (Git, C++ concepts, understanding of Qt and KDE frameworks, visualization of themes + color palettes and color schemes), he also helped me to improve on my communication skills.

Future scope:

If interested, you can find the developments and code at this Github link: https://github.com/KDE/labplot/commits/thememanager?author=prakritibhrdwj

Please don't forget to give me your feedback🙂

23 Aug 2016 12:51pm GMT

Minuet 0.2: massive refactoring and Android version available

Minuet 0.2: massive refactoring and Android version available

Hi there,

It's been a while since my last blog post about Minuet but that doesn't mean we aren't moving it forward. Actually a lot of work has been done lately, mostly related to architecture improvements, UX revamping, refactoring, code convergence, and its availability on Android devices. Minuet is a quite recent KDE project (it's been developed since November, 2015) and I'm really delighted with what we achieved so far, given we are a small team made up of only two developers (including a GSoC student) and a designer.

So, keep reading for an overview on the improvements delivered in Minuet 0.2 (desktop version) and our journey towards the very first release of Minuet for Android devices :).

Architectural improvements and general refactoring

Minuet 0.1 already presented a somehow nice architecture, where all ear training exercises are defined in multiple JSON files, which are automatically merged by Minuet's core to make up the navigation menu. That makes it easy to maintain a huge number of exercises and add new ones with no changes in source code. Some technical debt regarding QML source code was identified though and, of course, challenges introduced by the advanced features we expect to address and the need to have Minuet running on other platforms (such as Android, iOS, and Windows) had to be properly tackled with a stronger and more flexible architecture.

The architecture improvements released in Minuet 0.2 address three fundamental aspects: JSON specification of ear training exercises, sound infrastructure, and UI/UX improvements.

New JSON structure for exercises specification

In Minuet 0.1, exercises were defined in multiple JSON files, where intervals/chords/scales/rhythms were defined alongwith the exercises where they appeared as possible answers:

        "name":"Ascending Melodic Intervals",
            "name":"Seconds", "options":[{
                "name":"Minor Second", "sequenceFromRoot":"1"
                "name":"Major Second", "sequenceFromRoot":"2"

Excerpt of exercise specification JSON file in Minuet 0.1

Although that allowed for defining new exercises with no changes in source code, music concepts definitions (e.g. the "Minor Second" and "Major Second" intervals) had to be duplicated in any other exercise category where they appear (e.g. in "Second and Thirds" and "Second to Octave" categories). That was a burden since it caused a lot of duplicated entries for those concepts appearing in multiple categories.

In Minuet 0.2, exercise specification JSON files were splitted in two different types: definitions JSON files and exercises JSON files. Definitions JSON files specify music content (scales, intercals, chords, and rhythm patterns) regardless of the exercise categories where they appear in:

  "definitions": [
      "tags": ["interval", "ascending", "2", "minor"],
      "name": "Minor Second",
      "sequence": "1"
      "tags": ["interval", "ascending", "2", "major"],
      "name": "Major Second",
      "sequence": "2"

Excerpt of definitions JSON file in Minuet 0.2

In the new architecture, music content definitions are marked with any number of tags. Those tags are used by exercises JSON files to collect the definitions which will make up a given exercise category. That makes the definition of new exercises as simple as querying definitions by the tags they were marked with:

  "exercises": [
      "name": "Intervals",
      "children": [
          "name": "Ascending Melodic Intervals",
          "and-tags": ["interval", "ascending"],
          "children": [
              "name": "Seconds",
              "or-tags": ["2"]
              "name": "Seconds and Thirds",
              "or-tags": ["2", "3"]
              "name": "Second to Octave",
              "or-tags": ["2", "3", "4", "tritone", "5", "6", "7", "8"]

Excerpt of exercises JSON file in Minuet 0.2

Note how any (sub-)category uses and-tags and/or or-tags to select the definitions marked with, respectively, all and/or any of the provided tags. Now, changes in definitions JSON files are propagated to all exercises JSON files. You can define any number of definitions and exercises JSON files, since both are merged into a single JSON file for each type.

Sound infrastructure

Minuet 0.1 relied on Drumstick library to implement the required MIDI capabilities to play exercises. That not only yielded a high coupling between Minuet's core and Drumstick but also added a number of run-time dependencies, such as TiMidity++ and freepats. As a consequence, and in spite of a basic system sanity check executed at first Minuet's run, we still got some broken audio infrastructure in some installations.

The new architecture released with Minuet 0.2 totally decouples the sound infrastructure from Minuet's core and sound backends for different platforms are now implemented as Qt plugins. That enabled the move to using Fluidsynth + GeneralUser GS soundfont as Minuet Desktop's sound backend, with no run-time dependencies. Minuet Android's sound backend was built on top of CSound + sf_GMbank soundfont.

New Minuet sound backends can be easily created by implementing the Minuet::ISoundBackend interface:

class MINUETINTERFACES_EXPORT ISoundBackend : public IPlugin  


public Q_SLOTS:  
    virtual void setPitch(qint8 pitch) = 0;
    virtual void setVolume(quint8 volume) = 0;
    virtual void setTempo(quint8 tempo) = 0;

    virtual void prepareFromExerciseOptions(QJsonArray selectedExerciseOptions) = 0;
    virtual void prepareFromMidiFile(const QString &fileName) = 0;

    virtual void play() = 0;
    virtual void pause() = 0;
    virtual void stop() = 0;
    virtual void reset() = 0;


Minuet sound backends must implement the Minuet::ISoundBackend interface

The API is quite straightforward. The most important service is provided by prepareFromExerciseOptions(), where all required steps to initialize/create the audio representation of a given exercise option (a specific interval, scale, chord, or rhythm pattern) should be executed. After that, the exercise can be played by invoking the play() method. The methods setPitch(), setVolume(), and setTempo() should be also implemented to adjust, respectively, the overall pitch deviation, the playing volume, and the playing speed.

UI/UX improvements

Minuet 0.2 is now totally based on QtQuickControls2 and, therefore, requires Qt 5.7 to build. The move to QtQuickControl2 is justified not only by its clean and simple API, but also because it allows for enhanced productivity and leverages code convergence. Enhanced UX and code convergence are ongoing efforts in Minuet, even though the codebase for Minuet Desktop and Minuet Android are already quite similar, differing only on the adopted sound backends.

Minuet for Android available in Google Play Store

Minuet 0.2: massive refactoring and Android version available Minuet for Android: splashscreen

We are glad to announce that Minuet 0.2 is available on Google Play Store.

Minuet for Android is the result of the nice work performed by Ayush Shash in Google Summer of Code 2016. After three months of intense work, struggling with different sound libraries for Android and diverse UX patterns for mobile applications, we are happy in making Minuet for Android available with all features already presented in its desktop counterpart.

The sound backend in Minuet for Android was implemented on top of CSound: a powerful domain-specific language for sound synthesis which works on Windows, OS X, Linux, Android, and iOS. Instead on using all those oscilators combinations and other complicated sound synthesis stuff, we again adopted soundfonts as audio samplers for CSound in Android.

Minuet 0.2: massive refactoring and Android version available Initial dashboard

Minuet for Android initial screen provides the user a simple dashboard with all top-level exercises categories. That allows for rapidly jumping to the subcategories which represents chords, intervals, rhythms, and scales ear training exercises. The UI is currently sticked to portrait mode in smartphones, although we're rethinking the UX strategy for tablets and larger devices.

Minuet 0.2: massive refactoring and Android version available The navigation drawer

A typical navigation drawer allows for the user to navigate through all exercise categories resulted from merging the available exercises JSON files. The source code responsible for loading and merging JSON files, creating the navigation menu, and dynamically exhibiting the exercise screen is 100% shared with Minuet Desktop.

Adapting the piano virtual keyboard to small form factors was a particularly challenging task. After some unsuccessful attempts, we ended up using some labels to identify the piano octaves, we constrained the visualization to a single octave and then implemented an automatic horizontal scroll to the keyboard region which encompasses the exercise being currently played.

Minuet 0.2: massive refactoring and Android version available Minuet 0.2: massive refactoring and Android version available Minuet 0.2: massive refactoring and Android version available Chord, scale modes, and rhythm patterns recognition exercises

The UI for running intervals, chords, scales, and rhythm patterns exercises is quite similar to Minuet Desktop's one. In order to keep it scalable for exercises with many available answers we implemented a vertical scroll inside "Available Answers" groupbox. The answer(s) selected by the user for a given exercise is(are) presented in the "Your Answer(s)" groupbox. Incorrect answers are shown with a red rectangle and can be clicked to have the associated right answer revealed.

Minuet 0.2: massive refactoring and Android version available Minuet for Android: about dialog

What's next?

As I mentioned before, Minuet is still on its infancy but I guess it's looking quite promising already :). Now, we'll concentrate our energies in merging remaining divergent code, stabilizing the architecture, making the last UI polishments and then work hard on providing really amazing music content. Addressing new platforms? Yes, that's also in our roadmap, hopefully :).

Minuet for Android wouldn't be possible without the support of the KDE community. Many thanks to Ayush Shah for the courage to brave this road, to Alessandro Longo for the amazing category icons, to the VDG team for valuable UI feedback, and to Aleix Pol for helping with Android cmake buildsystem.

Yeah! We are nearly one week away from QtCon. Dude, I'm excited to meet old friends and make new ones :) If you are heading Berlin and want to learn more about Minuet, I'll present a talk about it on Day 3 (saturday, 3rd September), at 3pm, in room A08.

Minuet 0.2: massive refactoring and Android version available

See you!

23 Aug 2016 5:32am GMT

22 Aug 2016

feedPlanet KDE

The How part (6) - Concatenating OSM way chunks

( This post is related to my GSoC project with Marble. For more information you can read the introductory post )


As of now, If you load an openstreetmap file containing linestrings such as highways, lanes or streets, in Marble and zoom to level 11, you will find that the highways or streets are not contiguous and appear as broken.

You will find the roads/streets as broken


Instead of getting contiguous roads



One of the primary reasons for this discontiguity is that often a particular highway/lane/street is described using multiple contiguous OSM way elements instead of a single OSM way element. Marble treats each of these specific way element as a linestring object. However Marble omits rendering any objects which are smaller than 2px, in order to improve rendering performance. Due to this, many of the OSM way elements, which are smaller than 2px don't get rendered. Hence the street appears broken since only those of its OSM way elements are rendered which are larger than 2px.

One of the reasons which I can think of and which justifies this highway description using multiple elements is that a street might be called by a certain name for a specific stretch and might be called by some other different name for the remaining stretch. However, at level 11 we are mostly concerned with the type of highways (primary, secondary, motorway , residential) rather than the specifics such as names.

Usually, the multiple OSM way elements of a single highway share the first and the last node ID references. For example consider <1n…2n> as an OSM way element where 1n and 2n corresponds to the first and last node IDs of the way. A highway described by an ordered list of node IDs 1 to 56 can then usually be represented by the following OSM way elements <1…5>, <5…13>, <13…28>, <28…36>, <36…56>

I exploited this way of representation to create a way concatenating module in the existing osm-module tool. For the above example, the module would concat all the 5 OSM way elements into a single OSM way element <1…56>

osm-simplify -t highway=* -w input.osm

The above command concatenates all the highways present in the input file and produces a new osm file as output.

Apart from solving the problem of discontinuity, way concatenation also results in data reduction since it is eliminating redundant node references and way elements. This data reduction in turn results in faster file parsing as well as improved rendering performance since now to render a single stretch of highway one only needs to create and render a single linestring object as opposed to multiple linestring objects.


The tricky part of coding this OSM way concatenator is actually coming up with an algorithm which concatenates all the linestrings present in an input file. Finally I and my mentors Dennis Nienhüser and Torsten Rahn were able to come up with a working algorithm for concatenating osm ways of a file in reasonable time (approximately O(n) time).

The algorithm involves a made up data structure called WayChunk which basically is a list of contiguous ways. It also stores a GeoDataVisualCategory which represents the type of linestring. For example in case of highways GeoDataVisualCategory will contain the kind of highway, whether it is a motorway, primary, secondary or a residential type of highway.

The algorithm utilizes a multi-hash-map to bundle together OSM way elements which share a common starting or terminating node. This multi hash map has nodeID's as keys and WayChunk's as the values. The idea is that at any given instant, this map will contain the starting and ending point of the ways which have been evaluated till now, as keys and the corresponding way chunk as the value pointed to by these keys. Now whenever we encounter a new way, and if it's starting or ending node matches with any of the existing way chunks as well as the type i.e. GeoDataVisualCategory of the way matches with the type of the way chunk, then this way is added to the way chunk and the values of the map are adjusted so that the map's keys are the starting or ending nodes of some way chunk and not the intermediary ones. This way, eventually, we are able to concat the multiple small OSM chunks of highways, railroads into singular way elements.

The reason we are using multi-hash-maps instead of regular hash maps is that at a particular node, two or more highways(linestrings) of different types may emanate or terminate. Hence a given node may be associated with two or more way chunks having different type(GeoDataVisualCategory).

The algorithm in more detail is described below:

 Iterate over all of the way elements having key=value tags specified during input
   Check if the first or the last node ID of the way is present in the multi-hash-map.
   If neither of the IDs are present
   If only the first ID is present in the map
     Check if any chunk exsits in the map which has the key as that of first ID and GeoDataVisualCategory as that of the way.
     If such a chunk exists
       Append the way to this chunk accordingly(reverse the way if required)
       Delete the first ID from the map
       Insert a new entry into the multi map having the key as last node ID of the way and value as that of the found chunk
     If not
   If only the last ID is present in the map
     Check if any chunk exsits in the map which has the key as that of last ID and GeoDataVisualCategory as that of the way.
     If such a chunk exists
       Append the way to this chunk accordingly(reverse the way if required)
       Delete the last ID from the map
       Insert a new entry into the multi map having the key as first node ID of the way and value as that of the found chunk
     If not
   If both the IDs are present in the map
     Check if any chunk exsits in the map which has the key as that of first ID and GeoDataVisualCategory as that of the way.
     Check if any chunk exsits in the map which has the key as that of last ID and GeoDataVisualCategory as that of the way.
     If both the chunks exist
       Append the way and the second chunk to the first chunk and modify the map accordingly
     If only first chunk exists
       Append the way to the first chunk and modify the map accordingly
     If only last chunk exists
       Append the way to this last chunk and modify the map accordingly
     If none of the chunks exist
 Finally iterate over all the WayChunks and merge the ways in each of their lists to form one single osm way for each chunk

 Create a new WayChunk
 Append the way to this new way chunk
 Set the GeoDataVisualCategory of the chunk as that of the way
 Insert two new entries in the multi map having the starting and ending node IDs of the way as keys and the created WayChunk as the  value.


The first image having discontiguous highways represents the raw input OSM file. This file has 2704 ways in total and has a size of 4.7 MB

The way-concatenator reduced the number of ways to 812 and the size to 2.9 MB. The second image having contiguous roads represent the output of the way concatenator.

If we remove the redundant nodes from the above output using the node reducing module described in the previous post, we get a resulting file having a size of 2.5MB. This node reducer removes 15146 redundant nodes (keeping the resolution at level 11).

If you suspect that due to node reduction there will loss in quality of rendering, then look at the below rendered image and compare it with the above ones.


The node reducer and the way concatenator have resulted in a size reduction of approx 46% for the above sample without any significant loss in rendering quality.

22 Aug 2016 11:30pm GMT