Category Archives: programming

New linter integration plugins for KDevelop

Hi there!
I’ve just moved some linter integration plugins to the KDE infrastructure (scratch repos), therefore making them generally available.
They are fairly simple plugins, all 3 of them are alike in that they just run an external tool, and bring the results (the issues found) into KDevelop’s GUI. The found issues then will be in the problems toolview, in their own separate tab. The tools can check either a single file or all files in the project. You can see the workflow and configuration options in the videos included. There are also user’s manuals and tech manuals in the docs directories of each repo.

This plugin integrates Clang’s static code analysis feature, providing C/C++ static code analysis.

Git repository:

This plugin integrates a linter called Pylint, and as the name suggests it’s a Python code analyzer.

Git repository:

This plugin integrates a linter called JSHint, and as the name suggests it’s a Javascript code analyzer.

Git repository:

New GUI for kdev-cppcheck

Hi there!

As you all probably know CppCheck is static code analyzer tool for C and C++. KDevelop has a plugin that provides a front-end for it, and the plugin is called kdev-cppcheck.

The good news is I’ve updated it’s GUI and now it uses the KDevelop Problem Checker Framework.

In the past it used to have it’s own toolview, where it showed issues in different formats (flat issue list, grouped by files, grouped by issue severity), based on the settings set in a KCM module.

Here’s a screenshot showing and example of this


What I’ve done is break up that KCM module, and create a per project settings window, and a general global settings window. The global settings window allows you to set the location of the cppcheck tool


The per project settings window allows one to set the rest: parameters, and what should be checked


Also the results area now shown in the problems toolview, just like problems found by the background parser, in it’s own tab.


Here’s a video showing the workflow

New GUI for kdev-krazy2

Hi there!

First of all let me introduce some concepts for readers who are unfamilair with them.

What is krayz2?

Krazy2 is a set of code tests (basically static code analysis) for KDE developers.

What is kdev-krazy2?

kdev-krazy is a plugin for KDevelop, that provides a frontend for Krazy2, so it can be run directly from KDevelop. The resulting issues also show up in KDevelop.

What’s changed?

I’ve given some love to this plugin lately: First I ported it to KF5 so it can run in the latest KDevelop. Now I’ve changed it’s GUI so it now uses the new KDevelop Problem Checker Framework.

Up until now the plugin had it’s own toolview. That’s where settings could be changed, analysis started, and that’s where the issues showed up. Let’s see some screenshots!

The first one shows the main KDevelop window, with the plugin loaded, showing the krazy2 toolview docked in the bottom (fairly large picture, feel free to click).


Clicking either the “Select paths” or “Select checkers” buttons shows settings dialogs, not surprisingly you can select paths and chekers in them. The next 2 screenshots shows those.



Finally the result of the analysis is shown in the toolview


All this was in the past. Now the settings can be changed in the per project settings window



The analysis can be started from the Run menu.


The results show up in the problems toolview, the same way that problems detected by the background parser, in a separate tab


Here’s a video showing how it all works


KDevelop Checker Framework – pushed

Hi there!

I’m pleased to announce that the KDevelop Checker Framework has been pushed to the KDevPlatform repository. Here are some details about it:

GUI changes

  • Moved ProblemModel to shell
  • Reworked the Problems toolview. Now it works like this:
    • ProblemModels are added to ProblemModelSet.
    • ProblemReporterFactory makes instances of ProblemsView.
    • ProblemsView takes the models from ProblemModelSet (also subscribes for updates about them, so if one is added or removed it can add/remove their views) and it provides a tabbed widget where the views for them can be added. It creates instances of ProblemTreeView which show the problems in ProblemModel, and adds them to the tabs. Also the tabs shows the number of problems in the ProblemModels.
    • The toolview will only add actions that are supported by the model (for example: filtering, grouping, reparsing, showing imports. Obviously reparsing doesn’t make sense for runtime problem checkers)

See the video:

  • First it shows that the “old” problem reporter still works as intended (which also uses the new code now)
  • Then from 1:07 onward it shows an example problem model/view working with randomly generated test data.
  • It shows the features of the new model(s), that is filtering by files/project and issue severity.
  • It also shows the grouping support (grouping by severity, and path.

ProblemModel details

  • Broke up ProblemModel into 2 parts
    • Base ProblemModel that provides the QAbstractItemModel interface for views and can use various ProblemStores to store problems. By default it uses FilteredProblemStore.
    • ProblemReporterModel is basically the old ProblemModel that grabs problems from DUChain, it’s a subclass of ProblemModel.
  • ProblemStore simply stores problems as a list (well technically it stores them in a tree, but it only has 1 level, so it’s a list). There’s no filtering, no grouping. It’s perfect for ProblemReporterModel since it does filtering itself when grabbing the problems from DUChain.
  • FilteredProblemStore DOES filtering, and grouping itself. It stores problems in a tree (ProblemStoreNode subclasses). The tree structure depends on the grouping method, which is implemented with GroupingStrategy subclasses.
  • Moved WatchedDocumentSet and it’s subclasses from ProblemModel to ProblemStore, as it is really a detail that the model itself doesn’t need, however ProblemStore which stores the problems needs it actually.
  • Created a new Problem class, DetectedProblem and moved both this and the “old” Problem class in under the IProblem interface. The intent here was to create a class with a clear interface for problems, which ProblemStore can simply store. I wanted to eventually clear the problems out of DUChain and replace the “old” Problem class with it. However I realized that it’s not practical because of the “show imports” feature which shows the problems from imported contexts. Unfortunately DUChain is the class that knows those, and it’s way too much work to get it out from it. Not to mention it doesn’t even make sense, since it’s really something that logically belongs there.

Using this new system is fairly straightforward:

All one has to do is instantiate a model, add it to the model set:

KDevelop::ILanguageController *lc =  KDevelop::ICore::self()->languageController();
KDevelop::ProblemModelSet *pms = lc->problemModelSet();
m_model = new KDevelop::ProblemModel(this);
pms->addModel(“Test”, m_model);

Then later inject problems into it:

KDevelop::DetectedProblem *p = new KDevelop::DetectedProblem();
p->setDescription(“Some message”);

Here’s a class diagram about the relevant classes:


kdev-krazy2 ported to KF5

Good news everyone!

The KDevelop frontend for Krazy tools has been ported to KF5, so it now works with the KF5 version of KDevelop.


KDevelop – Checker framework

Hi there!

So I got a slot for GSOC2015 to implement a “Checker framework” for KDevelop, therefore I have been and I will be working on it during the summer.

The project has 3 phases

  1. Create a framework that problem checker plugin developers can push issues into, so that they don’t have to create their own infrastructure for it (like models, views, toolviews for the views, etc)
  2. Update some of the already existing plugins to use this framework (kdev-krazy, kdev-cppcheck, kdev-valgrind)
  3. Implement 2 new checker tools using the framework (clang-check, pylint).

A little bottom-line explanation:

This framework will basically mean a common (obviously subclassable) model that can be used for storing problems, some infrastructure for holding such models, and views. The model will be a refactored, cleaned up version of the current ProblemModel that is used by the problem reporter plugin. The toolview of that plugin will also be cleaned up and refactored, and provide a better view for the model(s).

Up to now I’ve been already working on creating this framework.

  • Now it is a tabbed view, and the tabs show the number of problems in the currently shown view
  • I’ve also created a class that holds problem models, and those models automatically get a view in a tab in the problem toolview

I am now in the process of refactoring the ProblemModel.

Here are two screenshots comparing the “old” toolview with the “new” one:

20150327_000002297 20150531_000002772

Latest KDevelop plugin improvements

Hi there!
Let’s review what I’ve done to KDevelop’s kdev-cppcheck and kdev-valgrind plugins lately.

JSONized kdev-cppcheck and kdev-valgrind

This is fairly straightfoward: These plugins were still using the old .desktop plugin manifest files. Now they are using the embedded JSON manifests. This isn’t something user visible, but it’s needed as the old .desktop method is now deprecated.

Added the number of calls to the callgrind output of kdev-valgrind

Until now the callgrind output has only shown the IR and Inclusive IR fields. Now is shows the number of calls as well. Take a look at the pictures!


Reorganized the output of memcheck in kdev-valgrind

Until now kdev-valgrind’s memcheck output unfortunately didn’t show enough of the callstacks to be really useful. You couldn’t see where the problem exactly occured, or where it was stemming from! Now it shows the full backtrace + the auxilliary trace as well, so you can see what actually causes the problems. See the pictures!



Java applet woes with https

Last year I created a simple Asterisk ( a VOIP server software ) extension monitor java applet for a client. It worked fine, but there was a problem when trying to load it from a https URL. It kept throwing exceptions.
Since it doesn’t send or receive any sensitive information, and it works inside an office in a closed system, it wasn’t a problem, just had to make sure the applet is loaded from http.

However today I had to deal with the applet again, and I wanted to solve this problem this time. On Windows 8 ( Windows 7, and Linux with OpenJDK IcedTea plugin doesn’t seem to be affected this time ) it kept throwing me these exceptions:

at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at java.lang.Class.newInstance(Unknown Source)
at$ Source)
at$ Source)
at Method)
at Source)
at Source)
at Source)
at Source)
at Source)
at Source)
at$Initializer$ Source)
at Method)
at$Initializer.<clinit>(Unknown Source)
at Source)
at Source)
at<init>(Unknown Source)
at<init>(Unknown Source)
at Source)
at Source)
at$JarLoader.getJarFile(Unknown Source)
at$JarLoader.access$800(Unknown Source)
at$JarLoader$ Source)
at Method)
at$JarLoader.ensureOpen(Unknown Source)
at$JarLoader.<init>(Unknown Source)
at$ Source)
at Method)
at Source)
at Source)
at Source)
at sun.plugin2.applet.Plugin2ClassLoader$ Source)
at sun.plugin2.applet.Plugin2ClassLoader$ Source)
at Method)
at sun.plugin2.applet.Plugin2ClassLoader.findClassHelper(Unknown Source)
at sun.plugin2.applet.Applet2ClassLoader.findClass(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass0(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass0(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadCode(Unknown Source)
at sun.plugin2.applet.Plugin2Manager.initAppletAdapter(Unknown Source)
at sun.plugin2.applet.Plugin2Manager$ Source)
at Source)

Caused by: access denied (“java.lang.RuntimePermission” “loadLibrary.sunec”)
at Source)
at Source)
at java.lang.SecurityManager.checkPermission(Unknown Source)
at sun.plugin2.applet.AWTAppletSecurityManager.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkLink(Unknown Source)
at java.lang.Runtime.loadLibrary0(Unknown Source)
at java.lang.System.loadLibrary(Unknown Source)
at Method)

While I was googling around, I found this stackexchange discussion, that is about basically the same exception. So I tried the offered solution, and guess what? It worked.
So apparently the JRE doesn’t have permission to access it’s own libraries while running an applet from a https URL.

So to reiterate the solution: If for whatever reason you encounter this exception, try adding the following to your java.policy file in the JRE’s lib/security directory:

grant codeBase “file:${{java.ext.dirs}}/*” {

Interestingly enough, on Windows 7 the policy file already has this entry! Which is plain weird.

kdev-valgrind at work

I’m happy to report that it works! I didn’t have to actually change anything anymore, just set it up and run it using an example program.

Here are some screenshots, showing the KDevelop integrated memcheck, massif and callgrind tools at work:




KDevelop plugins, debug lessons learned

While working on kdev-valgrind, I learned some debug lessons about them, and kinda made up a smaller checklist for problems I’ve encountered.

Problem: plugin doesn’t load

  • Is the plugin installed to the right directory?
  • Is the plugin path set correctly? ( QT_PLUGIN_PATH )
  • Is the kdevelop version in the plugin manifest correct? ( .desktop file in KDE 4 style manifest )

Problem: when starting KDevelop KDE complains about missing .rc file for the plugin

  • Is the .rc file installed to the right directory? ( e.g.: /usr/share/kxmgui5/plugin/plugin.rc )
  • Is the .rc file named correctly and is it the same as set with setXMLFile in the plugin?
  • Is the .rc file named the same as the plugin’s name in IPlugin’s constructor?

Problem: plugin menu items don’t show up

  • Is the plugin loaded?
  • Check the possible problems in the section above