Porting Codevis to KDE

The Problem with C++ Tooling

An ISO accepted C++ tooling is inexistent, so each project will choose their own toolings based on personal preference, and sometimes, based on Corporations preferences, and unfortunately there's no common ground on what should be used. There are some programs that got the Standard by consensus, like CMake. But even tough, projects will choose handmade makefiles, KConfig, meson, autotools, and many others exist.

The same thing happens for Package Managers, each Linux distributtion has a variant of packages, and on top of that there's vcpkg, conan - each one with pros and cons.

The lack of a node or a cargo or a pip that's the entry point for the language makes it complex for developers to know where to start, and the most common idea is to build what doesn't exist, or manually install (via git submodules/git subtrees) things that are not disponible in your distribution or operating system.

How Codevis Started (Tools and Libraries)

Codevis started as an experiment to see if it would be possible to apply the ideas in the Large Scale C++ book by John Lakos. A small proof of concept was created three years ago, and we adopted a lot of libraries to be able to work fast keeping the quality high:

  • Qt (5 and 6)
  • soci (database layer used at CERN)
  • QuaZip (easy access to compressed files)
  • LLVM and CLang (parsing of C++ files)
  • Sqlite3 (our actual database)
  • Doxygen (Documentation)
  • Python (Plugins)
  • Catch2 (Tests)

And this is already a fair number of libraries, specially considering that those libraries also depend on others, keeping the Dependency graph quite large.

One problem that we had was to create a CI for all systems we targeted with all those libraries. both of the most common C++ package managers failed us:

  • conan did not had LLVM (and we indeed created patches for it, adding missing libraries)
  • vcpkg did not had some libraries that we needed, too.

Because of this we had to manually create base CI scripts that would download, compile, install the libraries that were not found on the package managers but this is frail, as any handwritten script is.

We started to look for a new home, and KDE was nice enough to host us. This gave us their amazing CI and buildsystems, that already had all the libraries we used, plus a few more.

So we were able to drop the handwritten scripts for, mostly, llvm.

Why did the change from Pure Qt to KDE Frameworks?

When you are inside of a system that works, and that offers powerful and battle tested libraries, it's worth to try to use them. There are many libraries in the KDE Frameworks that I wanted to use before but it was too hard to bring to windows if I'm not using craft, resembles to conan and knows how to build libraries and applications within the KDE universe.

Adding the necessary information to build Codevis in craft was much simpler than expected.:

  • clone craft-blueprints-kde
  • copy a program template and chagne it's name
  • point to the kde repository with a list of libraries it should use

The full codevis recipe for windows, mac and linux using craft is the following: Note that every line on runtimeDependencies and buildDependencies are a craft recipe inside of the same repository, so just by searching the folders it's easy to know what to add for your program.

import info
from Packager.CollectionPackagerBase import PackagerLists

class subinfo(info.infoclass):
    def setTargets(self):
        self.versionInfo.setDefaultValues()
        self.description = "Codevis is a software to visualize large software architectures."
        self.displayName = "Codevis"
        self.webpage = "http://invent.kde.org/sdk/codevis"
        self.svnTargets["master"] = "http://invent.kde.org/sdk/codevis.git"

    def setDependencies(self):
        self.buildDependencies["kde/frameworks/extra-cmake-modules"] = None
        self.runtimeDependencies["libs/llvm"] = None
        self.runtimeDependencies["libs/zlib"] = None
        self.runtimeDependencies["libs/catch2"] = None
        self.runtimeDependencies["qt-libs/quazip"] = None
        self.runtimeDependencies["libs/runtime"] = None
        self.runtimeDependencies["libs/qt5/qtbase"] = None

from Package.CMakePackageBase import *

class Package(CMakePackageBase):
    def __init__(self):
        CMakePackageBase.__init__(self)
        self.subinfo.options.configure.args += ["-DUSE_QT_WEBENGINE=OFF ", "-DCOMPILE_TESTS=OFF "]

    def createPackage(self):
        self.defines["executable"] = "bin\\codevis_desktop.exe"
        return TypePackager.createPackage(self)

How easy is to bring a 50 - 100K lines of code to KDE?

  • We adopted KConfig

With The build part fixed, it was time to adopt some libraries to remove some handwritten logic we had. I wrote a configuration to c++ parser to easily access configuration keys from .ini format, but this was the only project using it, so why not change to KConfig, that uses a XML based description for settings, and it's used by almost all programs within the KDE Infrastructure (and it certainly has way more unittests preventing breackages than what I have on my try)

  • We adopted KXmlGUI

KXMLGui is one of the killer features of the KDE Frameworks. It allow you to split the logic of your interface with a description of Menus and Toolbars in XML, and in runtime it provides some nice features like allowing the user to change the toolbars with any action registered within the system, and a searchable command pallete, that's something I use in all KDE applications on my machine, and I sure was missing this on Codevis.

  • We adopted KDocTools

Documentation is complex, but having an integrated documentation viewer and semantics ready, that could compile into hmtl with integrated search is impressive. Now we just need the time to actually write that documentation...

  • We adopted KNewStuff

KNewStuff is a technology that integrates with pling.com and allows to distribute certain types of downloadable goodies, like wallpapers - or in our case, plugins to improve the system with things that the main developers didn't had the time to do yet.

  • We adopted KNotification

Since the application takes a while to parse C++ code, or to run some plugins, KNotification is used to send a desktop notification to the user when an action ends. A small feature, but good for UX.

  • We adopted KTextEditor

We need to have a place for users to develop plugins for Codevis, so KTextEditor was not a hard choice, it's the editor that powers up Kate, one of the flagship applications from KDE. Using it has been extremely easy and fast, supporting syntax-highlihting for multiple formats.

An Honest, and unbiased, view

The work to port Codevis to use KDE libraries took around 2 weeks, and things were good. No major breakage and just some changes in behavior (mostly for the better). We also helped the KF6 libraries with ideas while discussing on their public channel in Matrix, and patches for some other programs while developing (such as Konsole, Kate, Konversation).

Nothing is perfect, but the outcome was a better, more stable, Codevis and the community was great while helping us understand how to use / handle specifics of a library - like KNotification using raw news without a corresponding call to a deleter. This was fixed by a comment on the Documentation stating that it auto-deletes itself.

Should Corporations Adopt KDE Libraries?

For sure. The libraries are really high quality, and there are more than 90 of them. Not using something that's already working and with tests, is a waste of money on the corporation side.

Are the devs Happy?

Yes, and I would use KDE Frameworks again.

The work for Codevis is sponsored by Bloomberg, and done by Codethink in the open, inside of the KDE Repositories.

Codevis Weekly Update

Welcome to the first "Codevis Weekly Update"

What is Codevis?

Codevis is a tool to help developers manage large codebases, sponsored by Bloomberg, developed by Codethink and hosted on the KDE Infrastructure, with all that, completely opensource with a permissive license. Codevis uses a mix of technologies to do what it does, mainly LLVM and Clang to do the heavy lifting of understanding C++ Codebases, Qt for Callback management (in the form of Signal/Slots), KDE Frameworks libraries for the desktop application, and pure Qt for the CLI application. The database layer is written with Soci , the same database layer used in CERN, targeting sqlite3.

But How does it work?

Codevis analyzes all the visible source code from your project and creates a graph database (using a relational database) in a way that the analyst can load and interpret information from the codebase without loading the codebase. The graph-database is comprehensive, and has all the information we think it's important, and also a lot of information that's good to have, with a bunch of information because why not. Since something that's not important for me could be really important for a company with billions of lines of code.

It just generates visualization?

No. Codevis also allows you to draw your software architecture and generate ready-to-compile c++ code from it. Think of this as a possibility to have C++ templates for complex projects tha are also visually documented. You can create libraries, classes, structures, connect them quickly on a dirty mockup during a meeting, and the output could be 60 c++ files on disk with all the classes, folder-hierarchy and CMake ready to compile.

This will not add any method or implement anything, but just the creation of the C++ files and CMake scripts from a small architecture meeting is pretty interesting in my point of view.

Is this still on?

It's been a Long long time without posting anything. Not that i'm lazy (well, a bit). But I have been working on a lot of things related to KDE this past few years, and I was finally able to release and opensource Codevis. I know this post is as small as a tweet, just checking if the integration is stil working

Konsole in 2021

This year konsole kept the momentum it gained in 2020, and implemented quite a lot of userful new features. We Finally implemented Reflow, thanks to the combined effort of me and Carlos Alves - that was one of the most requested features of konsole for the entire history of the project.

Ahmad Samir fixed tons of issues in konsole, all around the codebase, he's the person with most commits on konsole this year, praise to him.

KConfigXT Alternative Generator

I'm using for my own personal projects a generator for c++ preferences for quite a while, I'll not say that it's heavily tested as KConfigXT is, but it is also much more simple than it.

While talking about it to a fellow developer he asked me how hard it would be to port the thing to KConfig (as the main backend I used was QSettings) - and the result is quite nice, the port toook less than a day, and now my generator generates configurations for both KConfig and QSettings.

  • Example configuration:
preferences.conf

#include <QString>
#include <QStandardPaths>

Preferences {
    General {
        int beatsPerMinute = 60
    }
    Some {
        Inner {
            Group {
                int value = 10
            }
        }
    }
    Harmonica {
        QString partitureFolder = QStandardPaths::writableLocation(QStandardPaths::DocumentsLocation)
    }
}

For those that worked with KConfigXT, it's easy to see how much this is different from the xml that the tool uses. And differently from KConfigXT, the code is smaller, easier to read, and does not rely on magic enums, nor it has a lot of different possibilities to fine tune the settings - if you want to choose between runtime or compile time file, shared vs non shared config, etc.: KConfigXT is for you, mine is supposed to be simple and up to the point.

Konsole in 2020

Konsole is having a resurge in the moment, it's the terminal emulator of choice for the power user that wants to break the 4th wall in *nix systems. Right now it can do almost all the things I want it to do, and a few more.

Since last year you can use splits in Konsole, with full drag & drop support between tabs and windows.

{% include youtube.html id="f9Y1pul8smQ" %}

You can also use Konsole to quickly check for thumbnails of anything that dolphin can show you, just by hovering with the mouse (and depending of your configuration) pressing shift/control/alt. To my knowledge Konsole is the only terminal emulator that supports this.

{% include youtube.html id="8lic9xKG4lo" %}

Konsole and Splits

Some terminals like Tilix and Terminator offers the possibility to split the screen recursively, and I started to add the same thing to konsole. Konsole is usually said to be the swiss army knife of the terminal emulators, and if you didn't try it yet, please do. We offer quite a lot of things that no other terminal emulator offer.

Konsole and Wayland

Wayland needs a different mindset when you are programming, you cannot just assume things works the same way as in as X11. One of my first patches to konsole was the rewrite of the Tab Bar, and a different way to deal with Drag & Drop of the tabs. In my mind - and how wrong I was - I could assume that I was dragging to a konsole main window by querying the widget below the mouse.

The state of Terminal Emulators in Linux

We are seeing a strange trend nowadays: The terminal is being more widely used in windows, after they fixed the broken cmd.exe and MS is actually actively promoting their terminal applications like Visual Studio Code and the new Windows Terminal, but on the other hand the Unix world was always terminal based, even if you tend to use the Desktop Environment for your daily needs you probably also had a Terminal open somewhere.