KDiff3 master as git mergetool? Yes, please!

I like using kdiff3, I also like using git, I also like using bundles for applications. Let’s put the three together!

Set up the KDE git flatpak repo and install kdiff3

flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
flatpak remote-add --if-not-exists kdeapps --from https://distribute.kde.org/kdeapps.flatpakrepo
flatpak install kdeapps org.kde.kdiff3

Write a tiny shim around this so we can use it from git. Put it in /usr/bin/kdiff3 or $HOME/bin/kdiff3 if $PATH is set up to include bins from $HOME.

#/bin/sh
exec flatpak run org.kde.kdiff3 "$@"

Don’t forget to chmod +x kdiff3 it!

git mergetool should now pick up our kdiff3 wrapper automatically. So all that’s left to do is having a merge conflict and off we go with git mergetool

Advertisements

Konsole KDE Store Integration

Git master of Konsole recently grew integration for store.kde.org content along with a new category on the store for Konsole color schemes.

Soon you’ll be able to get a fresh look for your terminal without leaving the window or having to mess with copying around files manually!

Screenshot_20180307_132640.png

To celebrate I’ve also made a new color scheme based on Atom’s One Dark syntax theme.

Screenshot_20180223_155810.png

Happy Hacking!

KDE neon CMake Package Validation

In KDE neon‘s constant quest of raising the quality bar of KDE software and neon itself, I added a new tool to our set of quality assurance tools. CMake Package QA is meant to ensure that find_package() calls on CMake packages provided by config files (e.g. FooConfig.cmake files) do actually work.

The way this works is fairly simple. For just about every bit of KDE software we have packaged, we install the individual deb packages including dependencies one after the other and run a dummy CMakeLists.txt on any *Config.cmake file in that package.

As an example, we have libkproperty3-dev as a deb package. It contains KPropertyWidgetsConfig.cmake. We install the package and its dependencies, construct a dummy file, and run cmake on it during our cmake linting.

cmake_minimum_required(VERSION 3.0)
find_package(KPropertyWidgets REQUIRED)

This tests that running KPropertyWidgetsConfig.cmake works, ensuring that the cmake code itself is valid (bad syntax, missing includes, what have you…) and that our package is sound and including all dependencies it needs (to for example meet find_dependency macro calls).

As it turns out libkproperty3-dev is of insufficient quality. What a shame.