feed2list wird zum 01.01.2019 seinen Dienst einstellen
Suchen und blättern in Linux · Opensource
   Suchtreffer: 92
website Planet KDE
Planet KDE - http://planetKDE.org/

In October we held a Krita developers' sprint in Deventer. One of my goals for the sprint was to start implementing High Dynamic Range (HDR) display support for Krita. Now almost a month have passed and I am finally ready to publish some preliminary results of what I started during the sprint.

The funny thing is, before the sprint I had never seen what HDR picture even looks like! People around talked about that, shops listed displays with HDR support, documentation mentioned that, but what all this buzz was about? My original understanding was like "Krita passes 16-bit color to OpenGL, so we should already be ready for that". In Deventer I managed to play with Boud's display, which is basically one of few certified HDR displays with support of 1000 nits brightness, and found out that my original understanding was entirely wrong :)

Last couple of years the computer display industry has changed significantly. For almost 30 years people expected their monitors to look like normal paper. Displays were calibrated to look like a sheet of white paper illuminated by a strictly defined source of light (D65).

Now, with appearance of HDR technology, the things has changed. Displays don't try to emulate paper, they try to resemble real sources of light! For example, modern displays can show a sun beam piercing through a window not just like "a paper photo of a beam", but just as a real source of light getting directly into you eye! Basically, now the displays have LEDs that can shine as bright as a real sun, so why not use it? :) (Well, the display is only 1000 nits, and the sun 1.6 billion nits, but it's still very bright).

If you look at the original original EXR file you will see how the window "shines" from your screen, as if it were real
By itself, the idea of having a display that can send a sun-strength beam into your eye might be not a lot of fun, but the side effects might of the technology are quite neat.

In the first place, the displays supporting HDR do not work in the standard sRGB color space! Instead they use Rec. 2020, a color space widely used in cinematography. It has different primary colors for "green" and “red” channels, which means it can encode much more variations of greenish and reddish colors.

In the second place, instead of using traditional exponential gamma correction, they use Perceptual Quantizer (PQ), which not just extends the dynamic range to sun-bright values, but also allows to encode very dark areas, not available in usual sRGB.

Finally, all HDR displays transfer data in 10-bit mode! Even if one doesn't need real HDR features, having a 10-bit pipeline can improve both painters' and designers' workflow a lot!

Technical details

From the developer's point of view, the current state of HDR technology is a bit of a mess. It's really early days. The only platform where HDR is supported at the moment is Windows 10 (via DirectX).

Neither Linux nor OSX can handle the hardware in HDR mode currently. Therefore all the text below will be related to Windows-only case.

When the user switches the display into HDR mode, the OS automatically starts to communicate with it in p2020-pq mode. Obviously, all the colors that normal applications render in sRGB will be automatically converted. That is, if an application wants to render an image directly in p2020-pq, it should create a special "framebuffer" object (swap chain), set its colorspace to p2020-pq and ensure that all the internal textures have correct color space and bit depth.

In general, to ensure that the window is rendered in HDR mode, one should do the following:

  1. Create a DXGI swap chain with 10-bit or 16-bit pixel format
  2. Set the color space of that swap chain to either p2020-pq (for 10-bit mode) or scRGB (for 16-bit mode).
  3. Make sure all the intermediate textures/surfaces are rendered in 10/16-bit mode (to avoid loss of precision)
  4. Since the GUI is usually rendered on the same swap chain, one should also ensure that the GUI is converted from sRGB into the destination color space (either p2020-pq or scRGB)
In Krita we use Qt to render everything, including our OpenGL canvas widget. I had to go deep into Qt's code to find out that Qt unconditionally uses 8-bit color space for rendering windows. Therefore, even though Krita passes 16-bit textures to the system, the data is still converted into 8-bits somewhere in Qt/OpenGL. So I had to hack Qt significantly...

Making Qt and Angle support HDR

Here comes the most interesting part. We use Qt to access the system's OpenGL implementation. Traditionally, Qt would forward all our requests to the OpenGL implementation of the GPU driver, but... The problem is that quite a lot of OpenGL drivers on Windows are of "suboptimal quality". The quality of the drivers is so "questionable", that people from the Google Chromium project even wrote a special library that converts OpenGL calls into DirectX API calls and use it instead of calling OpenGL directly. The library is called Angle. And, yes, Qt also uses Angle.

Below is a sketch, showing the relation between all the libraries and APIs. As you can see, Angle provides two interfaces: EGL for creating windows, initializing surfaces configuring displays and traditional OpenGL for the rendering itself.

To allow switching of the surface's colorspace I had to hack Angle's EGL interface and, basically, implement three extensions for it:

After that I had to patch QTextureFormat a to support all these color spaces (previously, it supported sRGB only). So now, if you configure the default format before creating a QGuiApplication object, the frame buffer object (swap chain) will have it! :)

// set main frame buffer color space to scRGB
QSurfaceFormat fmt;
// ... skipped ...

// create the app (also initializes OpenGL implementation
// if compiled dynamically)
QApplication app(argc, argv);
return app.exec();

I have implemented a preliminary demo app that uses a patched Qt and shows an EXR image in HDR mode. Please check out the source code here:

Demo application itself:

Patched version of QtBase (based on Qt 5.11.2):

The application and Qt's patch are still work-in-progress, but I would really love to hear some feedback and ideas from KDE and Qt community about it. I would really love to push this code upstream to Qt/Angle when it is finished! :)

List of things to be done

  1. Color-convert Qt's internal GUI textures. Qt renders the GUI (like buttons, windows and text boxes) in a CPU memory (in sRGB color space), then uploads the stuff into an OpenGL texture and renders that into a frame buffer. Obviously, when the frame buffer is tagged with a non-sRGB color space, the result is incorrect --- the GUI becomes much brighter or darker than expected. I need to somehow mark all Qt's internal textures (surfaces?) with a color space tag, but I don't yet know how... Does anybody know how?
  2. Qt should also check if the extensions are actually supported by the implementation, e.g. when Qt uses a driver-provided implementation of OpenGL. Right now it tries to use the extensions without any asking :)
  3. The most difficult problem: OpenGL does not provide any means of finding out if a combination of frame buffer format and color space is actually supported by the hardware! A conventional way to check if the format/color space is supported: create an OpenGL frame buffer and set the desired color space. If the calls do not fail with error, then the mode is supported. But it doesn't fit the way how Qt selects it! Qt expects one to call a singleton QSurfaceFormat::setDefaultFormat() once and then proceed to creation of the application. If the creation fails, there is no way to recover! Does anybody have an idea how that could be done in the least hackish way?

I would really love to hear your questions and feedback on this topic! :)

text KDAB Training at Qt World Summit Berlin
Tue, 20 Nov 2018 11:32:38 GMT

KDAB is offering eight superb Training Classes in Berlin, you can see the list below, which includes one run by our long-term collaborator, froglogic. All the rest are delivered by KDAB engineers.

There are five classes in our Introductory group, and three in the Advanced. Read the descriptions carefully to see which one you’d like to attend. An Introductory class can be just what you need for a refresher, even if you’re an experienced programmer, as our trainers are always up-to-date with the latest tips.

Effective 3D in Qt
Introduction to CMake
Introduction to Qt/QML
Multithreading in Qt
Qt GUI Testing with Squish

Modern C++ – What’s New in C++17?
Profiling and Debugging for Linux
QML Applications Architecture



Effective 3D in Qt

with James Turner

Target Audience: Qt developers wishing to integrate 3d technology in their application.

Prerequisites: The audience is expected to have familiarity with basic QtQuick and OpenGL concepts, but no in-depth knowledge of them is required.

Course Description

Starting with the utility and enabler classes (for OpenGL, Vulkan and the upcoming Metal support), we will look at low level support for using OpenGL with QOpenGLWindow for rendering and event handling. We will also look at the support in the Widgets module.

Later we will show the technologies available in Qt that allow deep integration of Qt Quick 2 scenes with custom drawn OpenGL content. We will discuss the possibility of simply providing a Qt Quick overlay for an OpenGL scene. The discussion will then proceed to the creation of custom Qt Quick Items drawn using raw OpenGL commands, which can then be used from QML. We will also illustrate how to manually drive Qt Quick’s own rendering if we need to be in complete control of how and when the rendering happens.

Finally, we will look at Qt 3D and how to use its scene graphs and frame graphs to create high performance 3d rendering without requiring the specialist knowledge required when accessing OpenGL directly. Along the way we will introduce the Qt 3D renderer and input systems and how they are built on top of a flexible, highly threaded, Entity Component System (ECS) architecture that scales very well and is ripe for future additions.

You will learn how to:

  • create windows for 3d rendering
  • add a Qt Quick based UI to an OpenGL application
  • create custom high performance Qt Quick Items using OpenGL
  • integrate your own OpenGL renderer with the Qt Quick Renderer
  • construct a basic Qt 3D application
  • make a scene graph, display 3D graphical content using geometry, materials, textures
  • get Qt 3D maps onto the graphics pipeline
  • extend Qt 3D to use your own custom geometry
  • write custom materials and shaders
  • completely control the Qt 3D renderer dynamically at runtime using the Frame Graph
James Turner

Senior Software Engineer and team lead at KDAB, James has been developing with Qt since 2002. He contributes to the current maintenance of Mac platform support as well as the development of OpenGL and 3D support in Qt. James has a background in user-interface, graphics and simulation development as well as a long history of development on OS-X and prior versions of Mac OS. He is a lead developer on FlightGear, the open-source flight simulator, and holds a BSc in Computer Science.

Introduction to CMake

with Kevin Funk

Target Audience: C and C++ Developers who are interested in how to build their code.

Prerequisite: Experience with build systems.

“The best thing a build system can do is not get in the way”.

Course Description

CMake is the de facto standard build system for C and C++ outside of frameworks that require their own. It has earned this place by supporting the situations and special cases that arise in real projects.

Support for CMake within Qt is being significantly improved and there are longer term plans to switch to CMake for building Qt itself. It’s currently a good alter- native if you hit limitations in qmake.

This course will teach the basics of creating and building projects with CMake.  In recent years, CMake has introduced some cleaner and more precise constructs. The course will focus on the new constructs where possible.

Why learn CMake? CMake has broad functionality that covers many real world problems. Learning CMake enables you to solve advanced build requirements. This includes cross-platform builds, feature detection based on platform or available libraries, built- time configurable feature switches and custom build steps. CMake is increasingly widely adopted across the industry.

Kevin Funk

Kevin has actively developed with Qt/C++ since 2006 and has a special interest in tooling and profiling. He’s an active contributor to KDAB’s GammaRay analyzer (a high-level Qt application debugger) and has a strong emphasis on state machine tooling. He is co-maintainer of the KDevelop IDE, a powerful C/C++ development environment backed by Clang, and is pushing for cross-platform success inside KDE. Kevin holds a Masters Degree in Computer Science.

Introduction to Qt/QML

with Jan Marker

Target Audience: Developers and managers interested in learning the autonomy of a QML application.

Prerequisite: Knowing the basics of Qt at C++ level is an advantage but not a requirement.

Course Description

This training is an introduction to Qt Quick. On the one hand it will teach you how to compose fluid user interfaces with slick animations using the QML language. On the other hand it will teach you how you hook the QML side up to your business logic in C++.

Course contents

  • Connecting a QML UX with C++ business logic
  • Complex list views including data provided from C++ models
  • Custom objects implemented using Qt Quick scene graph
  • Profiling and best practices for optimal performance

Why learn Qt/QML? Designed to take people new to Qt or QML, from the basics to a deep functional understanding of best practices, this Qt/QML training will equip you with the skills and know-how to boost your productivity at work.

Jan Marker

Software Engineer at KDAB, Jan has been using Qt since 2009 when he started contributing to the KDE project. Since joining KDAB he has worked on multiple large Qt and QML projects, while more recently also developing Wayland compositors. Besides in-depth knowledge of Qt and C++, Jan also has a deep interest in other technologies like NodeJS. He holds a BSc in Computer Science.

Multithreading in Qt

with Kevin Krammer

Target Audience: Qt Developers interested in multithreaded programming.

Prerequisite: Knowledge and experience programming with Qt and C++. A basic understanding of multithreaded programming is an advantage but not required.

Course Description

Multithreaded programming is essential for developers to create fast and responsive applications on computers, phones, and embedded devices all with an increasing number of cores. Qt offers several mechanisms for multithreading; however, it can be difficult to know which to use and how to steer clear of common pitfalls. This course offers guidance how to write safe and efficient multithreaded code with Qt.

Topics include:

  • Basic multithreading concepts (threads, processes, data races, reentrency, shared data)
  • Synchronization primitives (mutexes, semaphores, condition variables)
  • Special concerns for Qt applications (cross-thread signals/slots, QObject thread affinity, the GUI thread)
  • Low-level multithreading with Qt (QThread, QThreadPool, QMutex, etc)
  • High-level multithreading with Qt (QtConcurrent)
  • Threading with Qt Model/View
  • A brief summary of atomic operations

Why learn about Multithreading with Qt? Multithreaded development is a complex subject where it is easy to write code that contains severe bugs yet looks correct. This training will provide a solid foundation for writing safe and effective multithreaded code in Qt applications.

Kevin Krammer

Senior Software Engineer and team lead at KDAB, Kevin has actively developed with Qt and contributed consistently to KDE since 2000. He is a founding member of the QtCentre website and has mentored at Google’s Summer of Code program for 10 years. One of KDAB’s most experienced trainers, Kevin keeps our training material up-to-date and has trained engineers from Blackberry, Lockheed Martin, Siemens and Safegate and many others. Kevin holds a BSc in Software and Communications Engineering.

Qt GUI Testing with Squish

with Tomasz Pawlowski

Prerequisites: The course is for developers and testers already familiar with the basic concepts of Qt.

Course Description

In order to achieve high quality applications during testing process all the functionality of the software shall be covered, including fully exercising GUI itself. For regression testing automating this process gives benefits, saving execution time and increasing accuracy. On the other hand, GUI Automation might be a challenge, as GUI may change significantly during a product life cycle.

In this course we learn how to design and implement cross-platform automated tests using Squish GUI Tester for Qt, QML & QtQuick applications that continue to work as your product evolves.

  • Introduction to GUI Testing
  • Squish Overview (installation, configuration)
  • Test Script Creation and Execution
    • Recording and Replaying Test Scripts
    • Verification Points (Properties, Screenshot, Visual)
    • Test Results and Logging
    • Squish API
    • Image-Based Lookup
  • Development of Test Cases at Business Level
  • Set-Up and Tear-Down Functions
  • Debugging Test Scripts
  • Object Recognition
  • Accessing Application Internals (Inspecting, Object Properties and Methods)
  • Synchronisation and Event Handling
  • Squish Command-Line Tools
  • Working with Multiple Applications
  • Hooking into Running Applications
  • Squish Integration with CI
Tomasz Pawlowski

Software engineer at froglogic, Tomasz started the adventure with Squish and GUI Testing in 2011, designing and implementing automated tests for a Flight Planning solution at Lufthansa Systems. In 2014 he joined froglogic and is conducting Squish trainings and consulting for many companies in Europe, India and the USA. Additionally, Tomasz is implementing Squish integrations. Tomasz has a degree in computer science from Nicolaus Copernicus University in Poland.


Modern C++ – What’s New in C++17?

with Giuseppe D’Angelo

Target Audience: C++ developers who want to know more about the new features introduced in C++17.

Prerequisite: Knowing the basics of C++11 is a requirement, though more advanced topics will be explained as needed.

Course Description

Starting with C++11 released in 2011, the C++ language and standard library have steadily evolved. At the end of 2017 the new C++17 standard was released, adding a sizable amount of useful new features. All major compilers already support most (if not all) of its features.

In this training, the most useful of the new features introduced in C++17 and its predecessor will be presented. In cases for which these features depend on features introduced in C++11 or C++14, these will be refreshed as well.

New library features being presented include the new types std::any, std::optional and std::variant, the new parallel algorithms, filesystem access, std::string_view and new operations on the container classes. The new language features range from ways to improve template code with fold expressions, constexpr if, and class template deduction over improvements of lambdas to structured bindings and initalizers in if and switch statements.

Why learn what’s new in C++17? C++ is the language that powers most applications written with Qt. To make the most out of the language, developers need to know its capabilities and pitfalls, and keep up with the incremental changes done in new releases. Doing so rewards them with ways to write easier, faster, cleaner and safer code

Giuseppe D’Angelo

Senior Software Engineer at KDAB, Giuseppe is a long-time contributor to Qt, having used Qt and C++ since 2000, and is an Approver in the Qt Project. His contributions in Qt range from containers and regular expressions to GUI, Widgets and OpenGL. A free software passionate and UNIX specialist, before joining KDAB, he organized conferences on opensource around Italy. He holds a BSc in Computer Science.

Profiling and Debugging for Linux

with Milian Wolff

Target audience: Developers who want to find and fix problems,

Prerequisite: Knowing the basics of C++ and Qt,

Course Description

This training introduces various tools, which help developers and testers in finding bugs and performance issues. This variant of the training focuses on Linux.

The tools presented cover a wide range of problems, from general purpose debugging and CPU profiling to Qt specific high-level analyzers. Often, it is relatively simple to run a tool, but interpreting the results, or even just using some of the more advanced tools, requires deep technical knowledge. The following tools will be covered:


  • General purpose debugger: GDB
  • Record and replay, reverse debugging: RR
  • Memory error detectors: AddressSanitizer
  • Thread error detectors: ThreadSanitizer
  • Various Qt built-in features
  • GammaRay to investigate internals of Qt Applications

Static Code Analysis

  • Compilers
  • Clazy


  • CPU: Linux perf and hotspot
  • Heap memory: heaptrack
Milian Wolff

Senior Software Engineer at KDAB, Milian leads the R&D in tooling and profiling in which he has a special interest. Milian created Massif-Visualizer and heaptrack, both of which are now used regularly to improve the performance of C++ and Qt applications. When not applying his knowledge to improving code-base performance for KDAB’s customers, Milian maintains QtWebChannel for the Qt Project and is co-maintainer of the KDevelop IDE. In 2015, Milian won KDE’s Akademy Award for his work on Clang integration. He has a Masters Degree in Physics.

QML Applications Architecture

with Tobias Koenig

Target audience: QML developers who want to learn about creating large-scale yet maintainable applications.

Prerequisite: Being comfortable with the basics of QML, as well as some familiarity with developing with C++ and Qt (QObject, signals & slots, properties, etc).

Course Description

QML is a great language for expressing user interfaces in a declarative, easy to understand way. It can however be difficult to scale up from small demo applications to fully featured, complex systems without paying too high a price in complexity, performance and maintainability. In this course, we explore different techniques to deal with these issues to enable you to scale up your applications while steering clear from the common pitfalls.

Topics include:

  • Custom QML items
  • C++ integration
  • Declarative coding
  • Multi-page application architectures
  • Code organization
Tobias Koenig

Senior Software Engineer at KDAB, Tobias has actively developed with Qt since 2001 and has been an active KDE contributor during this time. His contributions have been mainly to the KDE PIM project and the KDE libraries, but also to other open source projects.

There’s still seats left for the One-Day Training at Qt World Summit in Berlin!

Sign up…

The post KDAB Training at Qt World Summit Berlin appeared first on KDAB.

text Composing AST Matchers in clang-tidy
Tue, 20 Nov 2018 09:16:10 GMT

When creating clang-tidy checks, it is common to extract parts of AST Matcher expressions to local variables. I expanded on this in a previous blog.

auto nonAwesomeFunction = functionDecl(

  , this);

  , this);

Use of such variables establishes an emergent extension API for re-use in the checks, or in multiple checks you create which share matcher requirements.

When attempting to match items inside a ForStmt for example, we might encounter the difference in the AST depending on whether braces are used or not.


void foo()
    std::vector vec;
    int c = 0;
    for (int i = 0; i  100; ++i)

    for (int i = 0; i  100; ++i) {

In this case, we wish to match the push_back method inside a ForStmt body. The body item might be a CompoundStmt or the CallExpr we wish to match. We can match both cases with the anyOf matcher.

auto pushbackcall = callExpr(callee(functionDecl(hasName("push_back"))));

    , this);

Having to list the pushbackcall twice in the matcher is suboptimal. We ca do better by defining a new API function which we can use in AST Matcher expressions:

auto hasIgnoringBraces = [](auto const& Matcher)
    return anyOf(

With this in hand, we can simplify the original expression:

auto pushbackcall = callExpr(callee(functionDecl(hasName("push_back"))));

    , this);

This pattern of defining AST Matcher API using a lambda function finds use in other contexts. For example, sometimes we want to find and bind to an AST node if it is present, ignoring its absense if is not present.

For example, consider wishing to match struct declarations and match a copy constructor if present:

struct A

struct B
    B(B const&);

We can match the AST with the anyOf() and anything() matchers.

    , this);

This can be generalized into an optional() matcher:

auto optional = [](auto const& Matcher)
    return anyOf(

The anything() matcher matches, well, anything. It can also match nothing because of the fact that a matcher written inside another matcher matches itself.

That is, matchers such as


match ‘trivially’.

If a functionDecl() in fact binds to a method, then the derived type can be used in the matcher:


The optional matcher can be used as expected:

    , this);

Yet another problem writers of clang-tidy checks will find is that AST nodes CallExpr and CXXConstructExpr do not share a common base representing the ability to take expressions as arguments. This means that separate matchers are required for calls and constructions.

Again, we can solve this problem generically by creating a composition function:

auto callOrConstruct = [](auto const& Matcher)
    return expr(anyOf(

which reads as ‘an Expression which is any of a call expression or a construct expression’.

It can be used in place of either in matcher expressions:

        hasArgument(0, integerLiteral().bind("port_literal"))
    , this);

Creating composition functions like this is a very convenient way to simplify and create maintainable matchers in your clang-tidy checks. A recently published RFC on the topic of making clang-tidy checks easier to write proposes some other conveniences which can be implemented in this manner.

text Bugsquashing Day
Tue, 20 Nov 2018 09:00:36 GMT
On the 2nd of December, the Kdenlive team will be having a bug squash day in preparation for the major refactoring release due in April 2019. This is a great opportunity for interested developers to participate in the project. The team has triaged hundreds of reports, closing more than a hundred of them in the past month. We have also  made a list of entry level bugs you can get started with. For the more seasoned developers, there are plenty of optionsbe it a shiny feature request or a challenge to polish some non-trivial edges. To hack Kdenlive you need to know C++, Qt, QML or KDE Frameworks. Those with knowledge of C can join the fun by improving MLT, the multimedia framework Kdenlive runs on. Those with no programming experience can join in testing fixes and features, as well as triaging more bug reports.
You can find the list of proposed bugs to solve in our workboard under “low hanging / junior jobs” section here.
Help spread the word and join us!

Getting started


Contact us
IRC – #kdenlive on Freenode
Telegram – https://t.me/kdenlive
Build it
GNU/Linux instructions can be found here.
Windows instructions can be found here.
Get a developer account
To participate in bug squashing, you need a KDE Identity account.
Submit your patches
Here is some information on how to submit a patch.
Learn more about Phabricator
Get familiar with Phabricator.

text Getting Started With Qt for WebAssembly
Mon, 19 Nov 2018 12:37:46 GMT

We’ve previously blogged about some of the features of Qt for WebAssembly. In this blog post we’ll take a look at how to get started: building Qt, building your application, and finally deploying the application.

If you would like to know more about this topic, then please join me for the Qt for WebAssembly webinar on November 27th.


The first step is installing emscripten. Please refer to the emscripten documentation for how to do so, and also note that Qt requires a unix host system: GNU/linux, macOS, or Windows subsystem for Linux. When done you should have a working em++ compiler in the path:

$ em++ --version
emcc (Emscripten gcc/clang-like replacement) 1.38.16 (commit 7a0e27441eda6cb0e3f1210e6837cae4b080ab4c)

Qt for WebAssembly applications are also Emscripten-based applications. Qt makes use of many of its features and so can application code.


Next, install the Qt 5.12 sources, for example using the online installer:


Build Qt from source and specify that we are cross-compiling for wasm using emscripten:

$ ~/Qt/5.12.0/Src/configure -xplatform wasm-emscripten -nomake examples
$ make

This Qt build is different from standard desktop builds in two additional ways: It is a static build, and does not support threads. Depending on how your application is structured and which features you use this may pose a problem. One way to find out is to make a separate “-static -no-feature-thread” desktop Qt build, and then debug/fix any issues there. The reason this may be preferable is that the build-debug cycle is usually faster on desktop, and you have a working debugger.

Your Application

Finally, build the application. Qmake is the currently supported build system.

$ /path/to/qt-wasm/qtbase/bin/qmake
$ make

This will produce several output files:

Name Producer Purpose
app.html Qt HTML container
qtloader.js Qt JS API for loading Qt apps
app.js emscripten app runtime and JS API
app.wasm emscripten app binary

Here, the app.wasm contains the majority (if not all) of the application and Qt code, while the .js files provide loading and run-time support.

The .html file provides the html page structure which contains the application as a element. The default version of this file displays a Qt logo during the loading and compile stage and contains a simple HTML page structure which makes the application use the entire browser viewport. You will probably want to replace this with application-specific branding and perhaps integrate with existing html content.

For qtloader.js our intention is to have a public and stable API for loading Qt-based applications, but we are not there yet and the API in that file is subject so change.

The files are plain data files and can be served from any http server; there is no requirement for any special active server component or plugin. Note that loading from the file system is not supported by current browsers. I use Python http.server for development, which works well.

When deploying applications we do recomned using a server that supports compression. The following table gives an indication of what the expected file sizes (for the main .wasm file) are:

Qt Modules gzip brotli
Core Gui 2.8MB 2.1MB
Core Gui Widgets 4.3MB 3.2MB
Core Gui Widgets Quick Charts 8.6MB 6.3MB

gzip is a good default choice as compressor and is supported by most web servers. brotli provides a nice compression gain and is supported by all wasm-enabled browsers.


The final result of all this should be your application running in a web browser, here represented by the Slate app created by my colleague Mitch. Slate is a Qt Quick Controls 2 based image editor.


A live version is available as well. If you’ve looked at this demo before the news is that it should be actually usable now: local file access is possible and there are few or none visual glitches.

For those that are attending Qt World Summit in Berlin next month: I look forward to seeing you there. If you a are not going then let me link to the webinar once again.

edit: Modified configure string in build instructions to include -nomake examples, since it will currently fail on the threading examples as some have noted in the comments. This will be fixed in Qt 5.12.1.

The post Getting Started With Qt for WebAssembly appeared first on Qt Blog.

text Contributing to the kde userbase wiki
Sun, 18 Nov 2018 12:26:54 GMT

This is the story about how I started more than one month ago contributing to the KDE project.

So, one month ago, I found a task on the Phabricator instance from KDE, about the deplorable state of the KDE userbase wiki. The wiki contains a lot of screenshot dating back to the KDE 4 era and some are even from the KDE 3 era. It’s a problem, because a wiki is something important in the user experience and can be really useful for new users and experienced ones alike.

Lucky for us, even though Plasma and the KDE applications did change a lot in the last few years, most of the changes are new features and UI/UX improvements, so most of the information are still up-to-date. So most of the work is only updating screenshots. But up-to-date screenshots are also quite important, because when the user see the old screenshots, he can think that the instructions are also outdated.

So I started, updating the screenshots one after the other. (Honestly when I started, I didn’t think it would take so long, not because the process was slow or difficult, but because of the amount of outdated screenshots.)

But I also learned a lot about KDE doing this. For example did you know that Blink (Chrome webengine) is a fork of Webkit (Safari webengine) and Webkit is a fork of KHTML (Konqueror webengine). I also learned about the existence of lesser-known KDE apps, for example Kile (a latex IDE), Calligra (an office suite), KFloppy (a floppy disk editor), …

As a non-native english speaker, I found out updating screenshots and quickly checking if the information is up-to-date is easier as I first though. There aren’t a lot of requirements, you only need a Phabricator account and the default Breeze theme installed. The Phabricator account is easy to create and the default theme should already be installed.

Then for each wiki entry, you only need to download the software, find all outdated screenshots in the wiki entry, take a new screenshot for each old screenshot, and upload the new screenshot.

For all icons, I quickly generated a png from the svg file with the following command:

convert -density 1200 -resize 128x128 -background transparent /usr/share/icons/breeze/apps/48/okular.svg okular.png

It’s not finished, there are still a lot of outdated screenshots in the wiki, but every day the amount decreases. :)

And you, dear reader, can also help. Like I said: this job doesn’t need any programming skills or perfect english skills, just a bit of motivation. If you need help, there are some instructions available to get started editing the page:

And you, dear reader, can also help. Like I said: this job doesn’t need any programming skills or perfect english skills, just a bit of motivation. If you need help, there are some instructions available to get started editing the wiki: Start Contributing, Markup help, Quick Start. You can also contact me: on the fediverse @carl@linuxrocks.online or on reddit (/u/ognarb1).

Thanks to XYQuadrat for proofreading this blog post. :D

text libqaccessibilityclient v0.3.0
Sun, 18 Nov 2018 11:26:37 GMT

Hi, I’ve been asked to make a new release of libqaccessibilityclient, which seemed like a good idea. So here we go: https://download.kde.org/stable/libqaccessibilityclient/ – version 0.3.0 is now available. I’d like to say thanks to the KDE sysadmins for being super fast.

Now if I wasn’t involved with the accessibility project, I’d have no clue what this is about… so What is libqaccessibilityclient?

It’s a small library that can help understand/use the accessibility information available on DBus. It could be used to write assistive applications such as screen readers. Right now my main purpose for it is to understand what’s going on, so I use it as debugging helper. There are now two small helper applications, one has been there before and shows a complete tree of accessibility objects, so the representation of applications as screen readers see them. The second one is new, it just dumps the same tree on the command line. I used this to find out KWin’s state, since doing anything while pressing alt-tab is hard. I could run it on the command line with a sleep and then see what KWin reported while I pressed alt-tab.

By the way, we’ve been organizing our work on a phabricator board here, feel free to comment and help out with some of the tasks, especially when it comes to Plasma keyboard handling.

text Video Editing for foss-gbg
Sun, 18 Nov 2018 11:13:42 GMT

Editing videos for foss-gbg and foss-north has turned into something that I do on almost a montly basis. I’ve tried a few workflows, but landed in using kdenlive and, when needed, Audacity. I’m not a very advanced audio person, so if kdenlive would incorporate basic noise reduction and a compressor, I stay within one tool.

Before I describe the actual process, I want to mention something about the hardware involved. There are so many things that you can do when producing this type of contents. However, all the pieces that you add to the puzzle is another point of failure. The motto is KISS – Keep It Simple Stupid. Hence, we use a single video camera with an integrated microphone. This is either an action cam, or a JVC video camera. In most cases this just works. In some cases the person talking has a microphone and then we try to place the camera close to a speaker. It has happened that we’ve recorded someone whispering just by the camera…

As we don’t have a dedicated microphone for the speaker, we get an audio stream that includes the reaction of the audience. That is in my opinion a good thing. It captures the mood of the event. However, we also get quite a lot of background noise which is bad. For this, I rely on this workflow from Rich Bowen. Basically, I extract the audio stream from the recording, massage it in Audacity, and then re-introduce it.

I’ve found it easier to cut the video prior to fixing the audio. This usually means find the start and the end of the talk, but in some cases it is more complex. E.g. removing parts of the Q&A due to reasons, or cutting out a demo that makes no sense when watching the video.

Once in Audacity, I generally pick out a “silent” part of the recoding to learn a noise profile. I then apply a noise reduction effect to the entire recording. This commonly produces a somewhat distorted sound (like if spoken into a can), but the voice of the speaker comes across nicely. After that, I usually apply a compressor effect to balance the loud and quite parts better. I’ve noticed that speakers often start out with a loud voice, and then softens the voice during the talk. For such cases, the compressor helps. It also helps balancing the sound level during Q&A where the audience might be quite or loud compared to the speaker depending on the layout of the venue.

Once the video and audio are cut and filtered, we need some intro and exit screens. I create these using LibreOffice Impress. I have created a template for the title page with the title of the talk and the name of the speaker, followed by a slide with room for the sponsor logo. This has a white background as logos mix badly with the crazy yellow colour of foss-gbg. Finally there is an exit slide which just says foss-gbg.se. I then export the slides to pdf and use ImageMagick to create pngs from them. Since I’m lazy, I just produce huge pngs that I mogrify to the right size. The entire flow looks like this:

libreoffice --headless --convert-to pdf slides.odp 
convert -density 300 -depth 8 -quality 85 slides.pdf slides.png
mogrify -resize 1920x1080 slides*.png

The very last step of the process is to overlap the intro and exit screens with the start and end of the video in a good way. I mix this with fading the audio in and out. The trickiest is fading in, as it is nice to hear the first words of the speaker but you don’t want the noise from the audience. I’ve found that no matter what, you need to fade in the sound, even if the fade only lasts for a fraction of a second. Fading out is easy as things usually ends in an applause.

Then it is all about clicking render, remembering to change the name of the output file and uploading to the foss-gbg YouTube channel.

Let’s have a bit more Usability & Productivity, shall we? The KDE Applications 18.12 release is right around the corner, and we got a lot of great improvements to some core KDE apps–some for that upcoming release, and some for the next one. And lots of other things too, of course!

New Features


UI Polish & Improvement

Next week, your name could be in this list! Not sure how? Just ask! I’ve helped mentor a number of new contributors recently and I’d love to help you, too! You can also check out https://community.kde.org/Get_Involved, and find out how you can help be a part of something that really matters. You don’t have to already be a programmer. I wasn’t when I got started. Try it, you’ll like it! We don’t bite!

If my efforts to perform, guide, and document this work seem useful and you’d like to see more of them, then consider becoming a patron on Patreon, LiberaPay, or PayPal. Also consider making a donation to the KDE e.V. foundation.

A common problem with bug reports received for KBibTeX is that the issue may already be fixed in the latest master in Git or that I can provide a fix which gets submitted to Git but then needs to be tested by the original bug reporter to verify that the issue has been indeed fixed for good.

For many distributions, no ‘Git builds' are available (or the bug reporter does not know if they exist or how to get them installed) or the bug reporter does not know how to fetch the source code, compile it, and run KBibTeX, despite the (somewhat too technical) documentation.

Therefore, I wrote a Bash script called run-kbibtex.sh which performs all the necessary (well, most) steps to get from zero to a running KBibTeX. The nicest thing is that all files (cloned Git repo, compiled and installed KBibTeX) are placed inside /tmp which means no root or sudo are required, nor are any permanent modifications made to the user&aposs system.

There is a README.txt file explaining the script in greater detail.

The only requirement is that the user installs the usual KDE-related development tools and libraries. If a tool or library is missing, the script will abort, but the error message (most likely some output from cmake) can be searched for in order to learn which package to install. Once this is done, simply restart run-kbibtex.sh until all steps succeed.

I have tested the script with several Linux distributions and gave earlier versions to bug reporters for testing, so I am almost sure that it will work as promised. Please send suggestions or bug reports via email to me.

comment count unavailable comments
text KDE Itinerary @ Paris Open Transport Meetup
Fri, 16 Nov 2018 15:15:00 GMT

I have been invited by Kisio Digital to present the work we have been doing around KDE Itinerary at the Paris Open Transport Meetup next week. The meetup is near Gare de Lyon and starts on Thursday at 19:00. Feel free to come by, I’m looking forward to discuss ideas on how to move KDE Itinerary forward.

While in Paris I’m also going to meet the team behind Navitia, an open source platform for processing and querying static and real-time ground transport data, in particular for local and nation-wide railway networks. That’s obviously very interesting for KDE Itinerary, as mentioned earlier access to dynamic information such as real-time traffic data is probably the biggest challenge for us.

And yes, I of course made sure to pick travel options that don’t have enough test coverage in KDE Itinerary yet ;-)

Linux packaging was a nightmare for years. But recently serious contenders came up claiming to solve the challenge: first containers changed how code is deployed on servers for good. And now a solution for the desktops is within reach. Meet Flatpak!


In the beginning I probably should admit that over the years I identified packaging within the Linux ecosystem as a fundamental problem. It prevented wider adoption of Linux in general, but especially on the desktop. I was kind of obsessed with the topic.

The general arguments were/are:

  • Due to a missing standard it was not easy enough for developers to package software. If they used one of the formats out there they could only target a sub-set of distributions. This lead to lower adoption of the software on Linux, making it a less attractive platform.
  • Since Linux was less attractive for developers, less applications were created on/ported to Linux. This lead to a smaller ecosystem. Thus it was less attractive to users since they could not find appealing or helpful applications.
  • Due to missing packages in an easy-accessible format, installing software was a challenge as soon as it was not packaged for the distribution in use. So Linux was a lot less attractive for users because few software was available.

History, server side

In hindsight I must say the situation was not as bad as I thought on the server level: Linux in the data center grew and grew. Packaging simply did not matter that much because admins were used to problems deploying applications on servers anyway and they had the proper knowledge (and time) to tackle challenges.

Additionally, the recent rise of container technologies like Docker had a massive impact: it made deploying of apps much easier and added other benefits like sandboxing, detailed access permissions, clearer responsibilities especially with dev and ops teams involved, and less dependency hell problems. Together with Kubernetes it seems as there is an actual standard evolving of how software is deployed on Linux servers.

To summarize, in the server ecosystem things never were as bad, and are quite good these days. Given that Azure serves more Linux servers than Windows servers there are reasons to believe that Linux is these days the dominant server platform and that Windows is more and more becoming a niche platform.

History, client side

On the desktop side things were bad right from the start. Distribution specific packaging made compatibility a serious problem, incompatible packaging formats with RPMs and DEBs made it worse. One reason why no package format ever won was probably that no solution offered real benefits above the other. Given today’s solutions for packaging software out there RPM and DEB are missing major advantages like sandboxing and permission systems. They are helplessly outdated, I question if they are suited for software packaging at all today.

There were attempts to solve the problem. There were attempts at standardization – for example via the LSB – but that did not gather enough attraction. There were platform agnostic packaging solutions. Most notably is Klik which started already 15 years ago and got later renamed to AppImage. But despite the good intentions and the ease of use it never gained serious attention over the years.

But with the approach of Docker things changed: people saw the benefits of container formats and the technology technology for such approaches was widely available. So people gave the idea another try: Flatpak.


Flatpak is a “technology for building and distributing desktop applications on Linux”. It is an attempt to establish an application container format for Linux based desktops and make them easy consumable.

According to the history of Flatpak the initial idea goes way back. Real work started in 2014, and the first release was in 2015. It was developed initially in the ecosystem of Fedora and Red Hat, but soon got attention from other distributions as well.

Many features look somewhat similar to the typical features associated with container tools like Docker:

  • Build for every distro
  • Consistent environments
  • Full control over dependencies
  • Easy to use build tools
  • Future-proof builds
  • Distribution of packages made easy

Additionally it features a sandboxing environment and a permissions system.

The most appealing feature for end users is that it makes it simple to install packages and that there are many packages available because developers only have to built them once to support a huge range of distributions.

By using Flatpak the software version is also not tied to the distribution update cycle. Flatpak can update all installed packages centrally as well.


One thing I like about Flatpak is that it was built with repositories (“shops”) baked right in. There is a large repository called flathub.org where developers can submit their applications to be found and consumed by users:

The interface is simple but has a somewhat proper design. Each application features screenshots and a summary. The apps themselves are grouped by categories. The ever changing list of new & updated apps shows that the list of apps is ever growing. A list of the two dozen most popular apps is available as well.

I am a total fan of Open Source but I do like the fact that there are multiple closed source apps listed in the store. It shows that the format can be used for such use cases. That is a sign of a healthy ecosystem. Also, there are quite a few games which is always good ��

Of course there is lots of room for improvement: at the time of writing there is no way to change or filter the sorting order of the lists. There is no popularity rating visible and no way to rate applications or leave comments.

Last but not least, there is currently little support from external vendors. While you find many closed source applications in Flathub, hardly any of them were provided by the software vendor. They were created by the community but are not affiliated with the vendors. To have a broader acceptance of Flatpak the support of software vendors is crucial, and this needs to be highlighted in the web page as well (“verified vendor” or similar).

Hosting your own hub

As mentioned Flatpak has repositories baked in, and it is well documented. It is easy to generate your own repository for your own flatpaks. This is especially appealing to projects or vendors who do not want to host their applications themselves.

While today it is more or less common to use a central market (Android, iOS, etc.) some still prefer to keep their code in there hands. It sometimes makes it easier to provide testing and development versions. Other use cases are software which is just developed and used in-house, or the mirroring of existing repositories for security or offline reasons: such use cases require local hubs, and it is no problem at all to bring them up with Flatpak.

Flatpak, distribution support

Flatpak is currently supported on most distributions. Many of them have the support built in right from the start, others, most notably Ubuntu, need to install some software first. But in general it is quite easy to get started – and once you did, there are hundreds of applications you can use.

What about the other solutions?

Of course Flatpak is not the only solution out there. After all, this is the open source world we are talking about, so there must be other solutions ��

Snap & Snapcraft

Snapcraft is a way to “deliver and update your app on any Linux distribution – for desktop, cloud, and Internet of Things.” The concept and idea behind it is somewhat similar to Flatpak, with a few notable differences:

  • Snapcraft also target servers, while Flatpak only targets desktops
  • Among the servers, Snapcraft additionally has iot devices as a specific target group
  • Snapcraft does not support additional repositories; there is only one central market place everyone needs to use, and there is no real way to change that

Some more technical differences are in the way packages are built, how the sandbox work and so on, but we will noch focus on those in this post.

The Snapcraft market place called snapcraft.io provides lists of applications, but is much more mature than Flathub: it has vendor testimonials, features verified accounts, multiple versions like beta or development can be picked from within the market, there are case stories, for each app additional blog posts are listed, there is integration with social accounts, you can even see the distribution by countries and Linux flavors.

And as you can see, Snapcraft is endorsed and supported by multiple companies today which are listed on the web page and which maintain their applications in the market.

Flathub has a lot to learn until it reaches the same level of maturity. However, while I’d say that snapcraft.io is much more mature than Flathub it also misses the possibility to rate packages, or just list them by popularity. Am I the only one who wants that?

The main disadvantage I see is the monopoly. snapcraft.io is tightly controlled by a single company (not a foundation or similar). It is of course Canonical’s full right to do so, and the company and many others argue that this is not different from what Apple does with iOS. However, the Linux ecosystem is not the Apple ecosystem, and in the Linux ecosystem there are often strong opinions about monopolies, closed source solutions and related topics which might lead to acceptance problems in the long term.

Also, technically it is not possible to launch your own central server for example for in-house development, or for hosting a local mirror, or to support offline environments or for other reasons. To me this is particularly surprising given that Snapcraft targets specifically iot devices, and I would run iot devices in an closed network wherever I can – thus being unable to connect to snapcraft.io. The only solution I was able to identify was running a http proxy, which is far from the optimal solution.

Another a little bit unusual feature of Snapcraft is that updates are installed automatically, thanks to theo.9dor for the hint:

The good news is that snaps are updated automatically in the background every day! 


While in the end a development model with auto deployments, even dozens per day, is a worthwhile goal I am not sure if everyone is there yet.

So while Snapcraft has a mature market place, targets much more use cases and provides more packages to this date, I do wonder how it will turn out in the long run given that we are talking about the Linux ecosystem here. And while Canonical has quite some experience to develop their own solutions outside the “rest” of the community, those attempts seldom worked out.


I’ve already mentioned AppImage above and I’ve written about it in the past when it was still called Klik. AppImage is “way for upstream developers to provide native binaries for Linux”. The result is basically a file that contains your entire application and which you can copy everywhere. It exists for more than a dozen years now.

The thing that is probably most worth mentioning about it is that it never caught on. After all, already long time ago it provided many impressive features, and made it possible to install software cross distribution. Many applications where also available as AppImage – and yet I never saw wider adoption. It seems to me that it only got traction recently because Snapcraft and Flatpak entered the market and kind of dragged it with them.

I’d love to understand why that is the case, or have an answer to the “why”. I only have few ideas but those are just ideas, and not explanations why AppImage, in all the years, never managed to become the Docker of the Linux desktop.

Maybe one problem was that it never featured a proper store: today we know from multiple examples on multiple platforms that a store can mean the difference. A central place for the users to browse, get a first idea of the app, leave comments and rate the application. Docker has a central “store”, Android and iOS have one, Flatpak and Snapcraft have one. However, AppImage never put a focus on that, and I do wonder if this was a missed opportunity. And no, appimage.github.io/apps is not a store.

Another difference to the other tools is that AppImage always focused on the Open Source tools. Don’t get me wrong, I appreciate it – but open source tools like Digikam were available on every distribution anyway. If AppImage would have focused to reach out to closed source software vendors as well, together with marketing this aggressively, maybe things would have turned out differently. You do not only need to make software easily available to users, you also need to make software available the people want.

Last but not least, AppImage always tried to provide as many features as possible, while it might have benefited from focusing on some and marketing them stronger. As an example, AppImage advertises that it can run with and without sandboxing. However, sandboxing is a large benefit of using such a solution to begin with. Another thing is integrated updates: there is a way to automatically update all appimages on a system, but it is not built in. If both would have been default and not optional, things maybe would have been different.

But again, these are just ideas, attempts to find explanations. I’d be happy if someone has better ideas.

Disadvantages of the Flatpak approach

There are some disadvantages with the Flatpak approach – or the Snapcraft one, or in general with any container approach. Most notably: libraries and dependencies.

The basic argument here is: all dependencies are kept in each package. This means:

  • Multiple copies of the same libraries on the system, leading to larger disk consumption
  • Multiple copies of the same library in the RAM during execution, leading to larger memory consumption
  • And probably most important: if a library has a security problem, each and every package has to be updated

Especially the last part is crucial: in case of a serious library security problem the user has to rely on each and every package vendor that they update the library in the package and release an updated version. With a dependency based system this is usually not the case.

People often compare this problem to the Windows or Java world were a similar situation exists. However, while the underlying problem is existent and serious, with Flatpak at least there is a sandbox and a permission system something which was not the case in former Windows versions.

There needs to be made a trade off between the advanced security through permissions and sandboxing vs the risk of having not-updated libraries in those packages. That trade off is not easily done.

But do we even need something like Flatpak?

This question might be strange, given the needs I identified in the past and my obvious enthusiasm for it. However, these days more and more apps are created as web applications – the importance of the desktop is shrinking. The dominant platform for users these days are mobile phones and tablets anyway. I would even go so far to say that in the future desktops will still be there but mainly to launch a web browser

But we are not there yet and today there is still the need for easy consumption of software on Linux desktops. I would have hoped though to see this technology and this much traction and distribution and vendor support 10 years ago.


Well – as I mentioned early on, I can get somewhat obsessed with the topic. And this much too long blog post shows this for sure ��

But as a conclusion I say that the days of difficult-to-install-software on Linux desktops are gone. I am not sure if Snapcraft or Flatpak will “win” the race, we have to see that.

At the same time we have to face that desktops in general are just not that important anymore. But until then, I am very happy that it became so much easier for me to install certain pieces of software in up2date versions on my machine.

text Qt Creator 4.8 Beta2 released
Fri, 16 Nov 2018 12:48:57 GMT

We are happy to announce the release of Qt Creator 4.8.0 Beta2!

This release comes with the many fixes that we have done since our first Beta release.

Additionally we upgraded the LLVM for the Clang code model to version 7.0, and our binary packages to the Qt 5.12 prerelease.

Get Qt Creator 4.8 Beta2

The opensource version is available on the Qt download page, and you find commercially licensed packages on the Qt Account Portal. Qt Creator 4.8 Beta2 is also available under Preview > Qt Creator 4.8.0-beta2 in the online installer. Please post issues in our bug tracker. You can also find us on IRC on #qt-creator on chat.freenode.net, and on the Qt Creator mailing list.

The post Qt Creator 4.8 Beta2 released appeared first on Qt Blog.

Hi! I had the opportunity to participate in QtCon Brasil 2018 as a speaker during the last weekend. It happened in São Paulo, which is a city that I haven't visited for a long time. My talk was about the integration of Qt applications and Computer Vision, specially focused on the mobile environment with QtQuick … Continue reading Talking about Qt and Computer Vision at QtCon Brasil 2018

text Atelier at Maker Faire and QtCon 2018!
Thu, 15 Nov 2018 17:08:42 GMT

These past couple weekends were a blast! On the weekend of November 3 and 4, it happened on Rio de Janeiro the first Maker Faire of Latin America. And I was able to do a talk about Atelier and the current status of our project. The event hold more than 1.500 people on the first... Continue Reading →

With Qt for Python released, it’s time to look at the powerful capabilities of these two technologies. This article details one solopreneur’s experiences.

The task

Back in 2016, I started developing a cross-platform file manager called fman. Its goal: To let you work with files more efficiently than Explorer on Windows or Finder on Mac. If you know Total Commander and Sublime Text, a combination of the two is what I am going for. Here’s what it looks like:

fman screenshot

Picking technologies for a desktop app

The biggest question, in the beginning, was which GUI framework to use. fman’s choice needs to tick the following boxes:

  • Cross-platform (Windows, Mac, Linux)
  • Good performance
  • Support for custom styles
  • Fast development

At the time, Electron was the most-hyped project. It has a lot of advantages: You can use proven web technologies. It runs on all platforms. Customizing the UI of your application is trivial by means of CSS. Overall, it’s a very powerful technology.

The big problem with Electron is performance. In particular, the startup time was too high for a file manager: On an admittedly old machine from 2010, simply launching Electron took five seconds.

I admit that my personal distaste for JavaScript also made it easier to discount Electron. Before I go off on a rant, let me give you just one detail that I find symptomatic: Do you know how JavaScript sorts numbers? Alphabetically. ’nuff said.

After considering a few technologies, I settled on Qt. It’s cross-platform, has great performance and supports custom styles. What’s more, you can use it from Python. This makes at least me orders of magnitude more productive than the default C++.

Writing a GUI with Python and Qt

Controlling Qt from Python is very easy. You simply install Python and use its package manager to fetch the Qt bindings. Gone are the days where you had to set up gigabytes of software, or even Qt. It literally takes two minutes. I wrote a Python Qt tutorial that shows the exact steps and sample code if you’re interested.

You can choose between two libraries for using Qt from Python:

  • PyQt is mature but requires you to purchase a license for commercial projects.
  • Qt for Python is a recent push by Qt the company to officially support Python. It’s offered under the LGPL and can thus often be used for free.

From a code perspective, it makes no difference because the APIs are virtually identical. fman uses PyQt because it is more mature. But given that Qt for Python is now officially supported, I hope to switch to it eventually.

Deploying to multiple platforms

Once you’ve written an application with Python and Qt, you want to bring it into the hands of your users. This turns out to be surprisingly hard.

It starts with packaging. That is, turning your source code into a standalone executable. Special Python libraries exist for solving this task. But they never “just work”. You may have to manually add DLLs that are only required on some Windows versions. Or avoid shipping shared libraries that are incompatible with those already present on the users’ systems. Or add special handling for one of your dependencies. Etc.

Then come installers. On Windows, most users expect a file such as AppSetup.exe. On Mac, it’s usually App.dmg. Whereas on Linux, the most common file formats are .deb.rpm and .pkg.tar.xz. Each of these technologies takes days to learn and set up. In total, I have spent weeks just creating fman installers for the various platforms.

Code signing

By default, operating systems show a warning when a user downloads and runs your app:

To prevent this, you need to code sign your application. This creates an electronic signature that lets the OS verify that the app really comes from you and has not been tampered with. Code signing requires a certificate, which acts like a private encryption key.

Obtaining a certificate differs across platforms. It’s easiest on Linux, where everyone can generate their own (GPG) key. On Mac, you purchase a Developer Certificate from Apple. Windows is the most bureaucratic: Certificate vendors need to verify your identity, your address etc. The cheapest and easiest way I found was to obtain a Comodo certificate through a reseller, then have them certify my business – not me as an individual.

Once you have a certificate, code signing involves a few more subtleties: On Windows and Ubuntu, you want to ensure that SHA256 is used for maximum compatibility. On Linux, unattended builds can be tricky because of the need to inject the passphrase for the GPG key. Overall, however, it’s doable.

Automatic updates

Like many modern applications, fman updates itself automatically. This enables a very rapid development cycle: I can release multiple new versions per day and get immediate feedback. Bugs are fixable in less than an hour. All users receive the fix immediately, so I don’t get support requests for outdated problems.

While automatic updates are a blessing, they have also been very expensive to set up. The tasks we have encountered so far – packaging, installers and code signing – took a month or two. Automatic updates alone required the same investment again.

The most difficult platform for automatic updates was Windows. fman uses a Google technology called Omaha, which is for instance used to update Chrome. I wrote a tutorial that explains how it works.

Automatic updates on Mac were much easier thanks to the Sparkle update framework. The main challenge was to interface with it via Objective-C from Python. Here too I wrote an article that shows you how to do it.

Linux was “cleanest” for automatic updates. This is because modern distributions all have a built-in package manager such as apt or pacman. The steps for enabling automatic updates were typically:

  • Host a “repository” for the respective package manager. This is just a collection of static files such as .deb installers and metafiles that describe them.
  • Upload the installer to the repository, regenerating the metafiles.
  • Create a “repository file”: It imports the repo into the user’s package manager.

Because fman supports four Linux distributions, this still required learning quite a few tools. But once you’ve done it for two package managers, the others are pretty similar.

OS Versions

There aren’t just different operating systems, there are also different versions of each OS. To support them, you must package your application on the earliest version. For instance, if you want your app to run on macOS 10.10+, then you need to build it on 10.10, not 10.14. Virtual machines are very useful for this. I show fman’s setup in a video.

fman’s build system

So how does fman cope with all this complexity? The answer is simple: A Python-based build script. It does everything from creating standalone executables to uploading to an update server. I feel strongly that releasing a desktop app should not take months, so am making it available as open source. Check it out if you are interested!


Python and Qt are great for writing desktop apps: Qt gives you speed, cross-platform support and stylability while Python makes you more productive. On the other hand, deployment is hard: Packaging, code signing, installers, and automatic updates require months of work. A new open source library called fbs aims to bring this down to minutes.

If you liked this post, you may also be interested in a webinar Michael is giving on the above topics. Sign up or watch it here: Americas / EMEA

The post Python and Qt: 3,000 hours of developer insight appeared first on Qt Blog.

Thank you to everyone who participated last Bug Day! We had a turnout of about six people, who worked through about half of the existing REPORTED (unconfirmed) Konsole bugs. Lots of good discussion occurred on #kde-bugs as well, thank you for joining the channel and being part of the team!

We will be holding a Bug Day on November 17th, 2018, focusing on Okular. Join at any time, the event will be occurring all day long!

This is a great opportunity for anyone, especially non-developers to get involved!

  1. Mascot_konqi-support-bughunt.pngCheck out our Bug Triaging guide for a primer on how to go about confirming and triaging bugs.
  2. Log into KDE Phabricator and join the Bugsquad!
  3. Join the #kde-bugs IRC channel on Freenode to chat with us in real-time as we go through the list.
  4. Open the shared Etherpad for this event (use your KDE Identity login) to select your block of bugs and cross them off.

If you need any help, contact me!

We promised Digital Atelier would be available in the Krita Shop after the succesful finish of the Fundraiser. A bit later than expected, we’ve updated the shop with the Digital Atelier brush preset bundle and tutorial download:

There are fifty great brush presents, more than thirty brush tips, twenty paper textures and almost twohours of in-depth video tutorial, working you through the process of creating new brush presets.

Digital Atelier sells for 39,95 euros, ex VAT.

And we’ve also created a new USB-card, with the newest stable version of Krita for all OSes. Includes Comics with Krita, Muses, Secrets of Krita and Animate with Krita tutorial packs.

It’s in the credit-card format again, which makes it easy to carry Krita with you wherever you go! Besides, this format lets us use the new Krita 4 splash screen by Tyson Tan.

The usb-card is available in two versions: as-is, for €29,95 and (manually) updated to the latest version of Krita for €34,95.

text KDevelop 5.3 released
Wed, 14 Nov 2018 09:00:00 GMT

KDevelop 5.3 released

A little less than a year after the release of KDevelop 5.2 and a little more than 20 years after KDevelop's first official release, we are happy to announce the availability of KDevelop 5.3 today. Below is a summary of the significant changes.

We plan to do a 5.3.1 stabilization release soon, should any major issues show up.


With 5.1, KDevelop got a new menu entry Analyzer which features a set of actions to work with analyzer-like plugins. For 5.2 the runtime analyzer Heaptrack and the static analyzer cppcheck have been added. During the last 5.3 development phase, we added another analyzer plugin which now is shipped to you out of the box:


Clazy is a clang analyzer plugin specialized on Qt-using code, and can now also be run from within KDevelop by default, showing issues inline.

Screenshot of KDevelop with dialog for project-specific Clazy settings, with clazy running in the background

The KDevelop plugin for Clang-Tidy support had been developed and released independently until after the feature freeze of KDevelop 5.3. It will be released as part of KDevelop starting with version 5.4.

Internal changes

With all the Analyzers integration available, KDevelop's own codebase has been subject for their application as well. Lots of code has been optimized and, where indicated by the analyzers, stabilized. At the same time modernization to the new standards of C++ and Qt5 has been continued with the analyzers aid, so it can be seen only in the copyright headers KDevelop was founded in 1998 .

Improved C++ support

A lot of work was done on stabilizing and improving our clang-based C++ language support. Notable fixes include:

  • Clang: include tooltips: fix range check. (commit. code review D14865)
  • Allow overriding the path to the builtin clang compiler headers. (commit. See bug #393779)
  • Always use the clang builtin headers for the libclang version we use. (commit. fixes bug #387005. code review D12331)
  • Group completion requests and only handle the last one. (commit. code review D12298)
  • Fix Template (Class/Function) Signatures in Clang Code Completion. (commit. fixes bug #368544. fixes bug #377397. code review D10277)
  • Workaround: find declarations for constructor argument hints. (commit. code review D9745)
  • Clang: Improve argument hint code completion. (commit. code review D9725)

Improved PHP language support

Thanks to Heinz Wiesinger we've got many improvements for the PHP language support.

  • Much improved support for PHP Namespaces
  • Added support for Generators and Generator delegation
  • Updated and expanded the integrated documentation of PHP internals
  • Added support for PHP 7's context sensitive lexer
  • Install the parser as a library so it can be used by other projects (currently, umbrello can use it) (Ralf Habacker)
  • Improved type detection of object properties
  • Added support for the object typehint
  • Better support for ClassNameReferences (instanceof)
  • Expression syntax support improvements, particularly around 'print'
  • Allow optional function parameters before non-optional ones (Matthijs Tijink)
  • Added support for magic constants __DIR__ and __TRAIT__

Improved Python language support

The developers have been concentrating on fixing bugs, which already have been added into the 5.2 series.

There are a couple of improved features in 5.3:

Support for other platforms

KDevelop is written with portability in mind, and relies on Qt for solving the big part there, so next to the original "unixoid" platforms like Linux distributions and the BSD derivatives, other platforms with Qt coverage are in good reach as well, if people do the final pushing. So far Microsoft Windows has been another supported platform, and there is some experimental, but maintainer-seeking support for macOS. Some porters of Haiku, the BeOS inspired Open Source operating system, have done porting as well, building on the work done for other Qt-based software. For KDevelop 5.3 the small patch still needed has been applied to KDevelop now, so the Haiku ports recipe for KDevelop no longer needs it.

KDevelop is already in the HaikuDepot, currently still at version 5.2.2. It will be updated to 5.3.0 once the release has happened.

KDevelop 5.3 Beta on Haiku

Note to packagers

The Clazy support as mentioned above has a recommended optional runtime dependency, clazy, more specifically the clazy-standalone binary. Currently clazy is only packaged and made available to their users by a few distributions, e.g. Arch Linux, openSUSE Tumbleweed or OpenMandriva,

If your distribution has not yet looked into packaging clazy, please consider to do so. Next to enabling the Clazy support feature in KDevelop, it allows developers to easily fix and optimize their Qt-based software, resulting in a less buggy and more performant software again for you.

You can find more information in the the release announcement of the currently latest clazy release, 1.4.

Get it

Together with the source code, we again provide a prebuilt one-file-executable for 64-bit Linux (AppImage), as well as binary installers for 32- and 64-bit Microsoft Windows. You can find them on our download page.

The 5.3.0 source code and signatures can be downloaded from here.

Should you find any issues in KDevelop 5.3, please let us know in the bug tracker.

kossebau Wed, 2018/11/14 - 10:00

text Elisa in FreeBSD
Tue, 13 Nov 2018 13:08:36 GMT

Elisa (product page, release announcements blog) is a music player designer for excellent integration into the KDE Plasma desktop (but of course it runs everywhere, including some non-Free platforms). I had used it a few times, but had not gotten around to packaging it. So today I threw together a FreeBSD port of Elisa, and you’ll be able to install it from official packages whenever the package cluster gets around to it.

Screenshot of pkg info for ElisaI say “threw together” because it took me only a half hour (most of that was just building it a half-dozen times in different ways). The Elisa code itself is very straightforward and nice. It doesn’t even spit out a single warning with Clang 6 on FreeBSD. That’s an indicator (for me, anyway) of good code. So if you want more music on FreeBSD, it’s there! (And the multimedia controls work from the SDDM lock screen, too)

Last month French publisher D-Booker released the 2nd edition of Timothée Giet’s book “Dessin et peinture numérique avec Krita”.

The first edition was written for Krita 2.9.11, almost three years ago. A lot of things have changed since then! So Timothée has completely updated this new edition for Krita version 4.1. There are also a number of  notes about the new features in Krita 4.

And more-over, D-Booker worked again on updating and improving the French translation of Krita! Thanks again to D-Booker edition for their contribution.

You can order this book directly from the publisher’s website. There is both a digital edition (pdf or epub) as well as a paper edition.

text Interview with HoldXtoRevive
Mon, 12 Nov 2018 08:00:51 GMT

Could you tell us something about yourself?

I’m Brigette, but I go mainly go by my online handle of HoldXtoRevive. I’m from the UK and mostly known as a fanartist.

Do you paint professionally, as a hobby artist, or both?

I have had a few commissions but outside that I would call myself a hobbyist. I would love to work professionally at some point.

What genre(s) do you work in?

I do semi-realistic sci-fi art. I most recently I have been drawing character portraits inspired from the Art Nouveau style, the majority of it has been fanart of a few different Sci-fi games.

Whose work inspires you most — who are your role models as an artist?

It’s hard to list them all really. Top of the list would be my other half, RedSkittlez, who is an amazing concept and character artist, also my friends Blazbaros, SilverBones and many more that would cause this to go on for too long.

Outside of my friends I would say Charles Walton, Pete Mohrbacher and Valentina Remenar to name a few.

How and when did you get to try digital painting for the first time?

About 4 years ago I downloaded GIMP as I wanted to get back into art after not drawing for about 15 years. I got a simple drawing tablet soon after and things just progressed from there.

What makes you choose digital over traditional painting?

The flexibility and practicality of it. Whilst I would love to try traditional acquiring, maintaining and storing supplies is not easy for me.

How did you find out about Krita?

My partner was looking at alternatives to photoshop and came across it via a youtube video. He recommended me to try it out.

What was your first impression?

How clean the UI is and how all of the tools where easy to find, and the fun I had messing with the brushes.

What do you love about Krita?

The fact it was really easy to get to grips with, yet I can tell there is more I can get from it. Also the autosave.

What do you think needs improvement in Krita? Is there anything that really annoys you?

I would like a brightness/contrast slider alongside the curve for ease of use. It would also be nice if the adjustment windows would not close when the autosave kicks in.

What sets Krita apart from the other tools that you use?

I have not used many programs before I can across Krita. But the thing that jumped out at me was the ease of use and it had everything I wanted in an art program, I know that if I want to try animation I do not need to go and find another program.

If you had to pick one favourite of all your work done in Krita so far, what would it be, and why?

That is hard to say, but in a pinch I would say the one titled “Saladin’s White Wolf”. I was really happy how the background came out, it was also the one to be picked out and promoted by Bungie on their twitter.

What techniques and brushes did you use in it?

For the most part I use a multiply layer over flats for shading. My main brushes are just the basic tip (gaussian), basic wet soft and the soft smudge brush.

Where can people see more of your work?

Over on my DeviantArt page: https://www.deviantart.com/holdxtorevive
And my twitter: https://twitter.com/HoldX2ReviveART

Anything else you’d like to share?

I’m bad with words but I want to show appreciation to the Krita crew for making this wonderful program and to everyone who has supported and encouraged me.

text Future Developments in clang-query
Sun, 11 Nov 2018 22:46:53 GMT

Getting started – clang-tidy AST Matchers

Over the last few weeks I published some blogs on the Visual C++ blog about Clang AST Matchers. The series can be found here:

I am not aware of any similar series existing which covers creation of clang-tidy checks, and use of clang-query to inspect the Clang AST and assist in the construction of AST Matcher expressions. I hope the series is useful to anyone attempting to write clang-tidy checks. Several people have reported to me that they have previously tried and failed to create clang-tidy extensions, due to various issues, including lack of information tying it all together.

Other issues with clang-tidy include the fact that it relies on the “mental model” a compiler has of C++ source code, which might differ from the “mental model” of regular C++ developers. The compiler needs to have a very exact representation of the code, and needs to have a consistent design for the class hierarchy representing each standard-required feature. This leads to many classes and class hierarchies, and a difficulty in discovering what is relevant to a particular problem to be solved.

I noted several problems in those blog posts, namely:

  • clang-query does not show AST dumps and diagnostics at the same time<
  • Code completion does not work with clang-query on Windows
  • AST Matchers which are appropriate to use in contexts are difficult to discover
  • There is no tooling available to assist in discovery of source locations of AST nodes

Last week at code::dive in Wroclaw, I demonstrated tooling solutions to all of these problems. I look forward to video of that talk (and videos from the rest of the conference!) becoming available.

Meanwhile, I’ll publish some blog posts here showing the same new features in clang-query and clang-tidy.

clang-query in Compiler Explorer

Recent work by the Compiler Explorer maintainers adds the possibility to use source code tooling with the website. The compiler explorer contains new entries in a menu to enable a clang-tidy pane.

clang-tidy in Compiler Explorer

clang-tidy in Compiler Explorer

I demonstrated use of compiler explorer to use the clang-query tool at the code::dive conference, building upon the recent work by the compiler explorer developers. This feature will get upstream in time, but can be used with my own AWS instance for now. This is suitable for exploration of the effect that changing source code has on match results, and orthogonally, the effect that changing the AST Matcher has on the match results. It is also accessible via cqe.steveire.com.

It is important to remember that Compiler Explorer is running clang-query in script mode, so it can process multiple let and match calls for example. The new command set print-matcher true helps distinguish the output from the matcher which causes the output. The help command is also available with listing of the new features.

The issue of clang-query not printing both diagnostic information and AST information at the same time means that users of the tool need to alternate between writing

set output diag


set output dump

to access the different content. Recently, I committed a change to make it possible to enable both output and diag output from clang-query at the same time. New commands follow the same structure as the set output command:

enable output dump
disable output dump

The set output command remains as an “exclusive” setting to enable only one output feature and disable all others.

Dumping possible AST Matchers

This command design also enables the possibility of extending the features which clang-query can output. Up to now, developers of clang-tidy extensions had to inspect the AST corresponding to their source code using clang-query and then use that understanding of the AST to create an AST Matcher expression.

That mapping to and from the AST “mental model” is not necessary. New features I am in the process of upstreaming to clang-query enable the output of AST Matchers which may be used with existing bound AST nodes. The command

enable output matcher

causes clang-query to print out all matcher expressions which can be combined with the bound node. This cuts out the requirement to dump the AST in such cases.

Inspecting the AST is still useful as a technique to discover possible AST Matchers and how they correspond to source code. For example if the functionDecl() matcher is already known and understood, it can be dumped to see that function calls are represented by the CallExpr in the Clang AST. Using the callExpr() AST Matcher and dumping possible matchers to use with it leads to the discovery that callee(functionDecl()) can be used to determine particulars of the function being called. Such discoveries are not possible by only reading AST output of clang-query.

Dumping possible Source Locations

The other important discovery space in creation of clang-tidy extensions is that of Source Locations and Source Ranges. Developers creating extensions must currently rely on the documentation of the Clang AST to discover available source locations which might be relevant. Usually though, developers have the opposite problem. They have source code, and they want to know how to access a source location from the AST node which corresponds semantically to that line and column in the source.

It is important to make use a semantically relevant source location in order to make reliable tools which refactor at scale and without human intervention. For example, a cursory inspection of the locations available from a FunctionDecl AST node might lead to the belief that the return type is available at the getBeginLoc() of the node.

However, this is immediately challenged by the C++11 trailing return type feature, where the actual return type is located at the end. For a semanticallly correct location, you must currently use


It should be possible to use getReturnTypeSourceRange(), but a bug in clang prevents that as it does not appreciate the trailing return types feature.

Once again, my new output feature of clang-query presents a solution to this discovery problem. The command

enable output srcloc

causes clang-query to output the source locations by accessor and caret corresponding to the source code for each of the bound nodes. By inspecting that output, developers of clang-tidy extensions can discover the correct expression (usually via the clang::TypeLoc heirarchy) corresponding to the source code location they are interested in refactoring.

Next Steps

I have made many more modifications to clang-query which I am in the process of upstreaming. My Compiler explorer instance is listed as the ‘clang-query-future’ tool, while the clang-query-trunk tool runs the current trunk version of clang-query. Both can be enabled for side-by-side comparison of the future clang-query with the exising one.

text Akademy 2018 Vienna
Sun, 11 Nov 2018 10:52:38 GMT

You have probably read a lot about Akademy 2018 recently, and how great it was.
For me it was a great experience too and this year I met a lot of KDE people, both old and new. This is always nice.
I arrived on Thursday so I had one day to set everything up and had a little bit of time to get to know the city.
On Friday evening I enjoyed the "Welcoming evening", but I was very surprised when Volker told me that I would be on stage the next day, talking about privacy.
He told me that someone should have informed me several days before. The scheduled speaker, Sebastian, couldn't make it to Akademy.

That was really a pity. If I had known earlier, I would have prepared a proper presentation, as I think I have a lot to say on the topic. I care a lot about good encryption support in KDE PIM and I have also been busy with Tails, a distribution strongly focused on privacy and anonymity.

So the next day I rambled a bit about encrypting mail headers (also known as Memory Hole), but it wasn't a great talk. It was also very stressful, as we started with a lot of delay: Setting up the audio took much longer than expected so all talks started late. As I was in such a hurry. I forgot a lot of what I wanted to say and failed to draft a greater picture for the privacy goal.

To compensate, let me say it here. Privacy starts with encrypting everything, starting with the content of the connection. This is mostly done via TLS. Here KDE is lacking some bits, as we cannot display the encryption methods, so we are sometimes forced to downgrade to old and insecure encryption methods without user visual feedback. But at least we support TLS everywhere! Unfortunately metadata is often enough to track where people are. To hide this information, we need TOR/VPN support within the applications. For most applications you can use the TOR network by running


but this is not really user-friendly.
It also has the disadvantage that you can't see if DNS requests are transmitted via the TOR tunnel. And then there's deamons, which you don't normally run from the command line. Furthermore, e.g. GnuPG has an option to enable TOR support and does not like to run using torsocks.

We need more control over the used TLS certificates and a way to display the TLS parameters, like accepted ciphers, protocol versions etc. Because at the moment KDE just asks you about unknown certificates, but you can't view/ control the other important details of a TLS connection to harden your system. Sure a default user can't decide whether something is good or not and a user may need to access some rotten company side. But we can provide a rating like ssllabs to show that the TLS connection is not good.

Another topic is to have a good support for TOR/VPN for applications and KDE in total in a user friendly way. And be sure that everything within these applications really uses the tunnel. I think at usecases like: I want TOR for everything except this application. After we have good solutions for those, we can focus on all the different applications. I haven't a good overview what each application should do in regards to the Privacy goal additionally.
As I'm busy within KDE PIM I see some things there:

  • Encrypting headers of mails to give less metadata to surveillance T742.
  • Make it possible to search in encrypted mails. Until now, the encrypted data are a binary blob to the search. The search is important to find mails again and is often a reason, why users do not use encrypted messages. T8447.
  • Protect Akregator webviewer against ad trackers T7528.
  • Add GnuPG TOFU (Trust On First Use) trust model support for KMail. With TOFU you will get more security without exchanging the gpg fingerprints. To make it clear, exchanging fingerprints gives more security than is achieved with TOFU, but it is exhausting. Only a small number of users exchange fingerprints. So many users will profit from having extra security by the TOFU security model being supported by KMail.

To move forward in reaching the privacy goal, I volunteered to organize a Sprint together with Louise Galathea. It will hopefully take place next Spring.

But back to the Akademy - two days of many talks which was pretty overwhelming, in a good way. I really enjoyed the mix of non technical talks and technical talks. My highlight was a talk about Kontact from Markus Feilner. It is interessting to see how users master issues around Kontact and what solutions they find. The talk would have benefited from Markus talking to KDE PIM before, as some of his suggestions weren't correct. But it was nice to see that there are happy users who love all bells and whistles from Kontact. The days after the talk I encountered another user who gave Kontact a try after years, because of that talk.

The BOF session started on Monday. I started the Mondey joining the Promo BoF to get some insights into how Promo works and how KDE PIM can have better promotion to attract new contributors. Together we created a rough plan to focus first on the new website and then create several blog posts to promote KDE PIM. Internaly we started to create several junior jobs and are discussing who can mentor new people when they come along. This is still ongoing and hopefully new people will join the new spirit of KDE PIM and aren't overwhelmed by the big amount of repositories.

After the AGM I joined the Distros BoF and was impressed by how many Distros have a KDE focus. We started to talk about issues regarding KDE and downstream. Especially if distros are time based, they need a lot of manpower to validate if bugs have already been fixed upstream, or if it is a downstream bug. The fast release cycle of different KDE bundels (Plasma, Frameworks & Applications) makes it even more difficult to follow. Maybe this BoF helps the distros to talk more about their issues in the distributions@kde.org mailinglist directly and solutions can be found for common issues.

The next day I attend KConfig BOF and talked about issues reagarding config migration and how to store config. Also a very common issue is that you need to get updates of config values in your application. KDE PIM has some examples of bad decisions reagarding config handeling, as you can configure a lot of stuff and everything is seperated into several files. But the seperation is not well formed from the beginning - an issue that's grown with the years. It is also written down as task to do cleanups and make the configs easier to consume. Because a clearer seperation also helps users who want to move their KDE PIM from one computer to another.

In the afternoon, the KDE PIM BoF took place, where we followed up on what has been going on since the last Akademy and what new things we want to do. We discussed a lot of how we can improve the onbording for KDE PIM.
As we want to make it easier for other applications to use PIM related data, we have a long standing goal to move single parts of KDE PIM to Frameworks. For the next KDE Application 18.12 we want to push syndication into Frameworks release. If we would have more manpower, we would move those things faster to Frameworks. If you are interested, or currently using some parts of KDE PIM within your application, it is a good idea to help us getting things cleaned up and moved to Frameworks. A bigger audience can consume PIM data more easily.

In the evening I joined the LGBT & Quuer Dinner and it was nice to cook together and chat.

The next days I mostly sat down and tried to get some smaller things fixed, like the issue with the suspend icon within the logout Applet. It is very good to sit next to Kai-Uwe so he could see and propose workarounds directly. Finally he found the hard coded color in the theme and the issue is solved in the next release.

Since there were many open discussions I did not managed to write a line of code within these days - I was busy talking. Additionally I wanted to see the newest KDE PIM within Debian, so this also took some time.

On Friday I took a train back to Germany. As Volker is always interested about live data from delays for improving KItinerary, he wished me some delays. And I had a lot of delay - I arrived in Berlin 12h later than expected. I had to sleep in Dresden, as the last train from Prag leaves at 18:07 towards Berlin. And since I missed that one, I had to take a local train to Dresden and there was no train anymore to Berlin. And it wasn't really late - just midnight. I never thought about that Dresden is that badly connected to rest of Germany...
But it was nice as I stayed at a friends place, who I wouldn't have met otherwise. From the improving KItinerary it was not a success, as I only got one update from Deutsche Bahn at 23:25 - telling me that the train from Leipzig to Berlin would use another track. The more useful information, that I never would reach that train would be more useful.

Week 44 in Usability & Productivity is coming right up! This week was a bit lighter in terms of the number of bullet points, but we got some really great new features, and there’s a lot of cool stuff in progress that I hope to be able to blog about next week! In the meantime, take a look at this week’s progress:

New Features


UI Polish & Improvement

Next week, your name could be in this list! Not sure how? Just ask! I’ve helped mentor a number of new contributors recently and I’d love to help you, too! You can also check out https://community.kde.org/Get_Involved, and find out how you can help be a part of something that really matters. You don’t have to already be a programmer. I wasn’t when I got started. Try it, you’ll like it! We don’t bite!

If my efforts to perform, guide, and document this work seem useful and you’d like to see more of them, then consider becoming a patron on Patreon, LiberaPay, or PayPal. Also consider making a donation to the KDE e.V. foundation.

text Automatic C++ comparison operators
Sat, 10 Nov 2018 09:15:00 GMT

C++ comparison operators are usually fairly straightforward to implement. Writing them by hand can however be quite error prone if there are many member variables to consider. Missing a single one of them will still compile and mostly work fine, apart from some hard to debug corner cases, such as misbehaving or crashing algorithms and containers, or data loss. Can we do better?


In KItinerary we have a number of classes representing schema.org types. Those are fairly straightforward value types with a number of properties, to be consumed both statically (by C++ code) and dynamically (by QML, Grantlee and JSON-LD de/serialization).

As implementing getters, setters, Q_PROPERTY statements, member variables, etc for about a hundred or so properties by hand would result in an unreasonable amount of boilerplate code, this is all done by a macro (example).

So far so good, but now we’d like to add comparison operators for those types. Specifically we needed operator== for optimizing away some memory allocations in case of non-changing write operations (similar to the common pattern of not emitting change signals in setter methods on non-changes). But the thoughts below are of course also applicable to any other comparison function, not just equality.


Ideally we’d find an alternatives to writing the comparison functions by hand that would either be impossible to break or would at least not fail silently (e.g. by producing compiler errors).


One idea would be to implement the comparison functions entirely generically by leveraging the property iteration support in QMetaObject. That is we iterate over all properties with the STORED flag and compare their values. This gets the job done, but has two drawbacks:

  • Comparison happens via QVariant, which means we have to register comparison operators for all types with the meta type system. That might actually be nice to have anyway, but it is limited to less-than and equal.
  • All property values are passed through QVariant, which in some situations can have a relevant performance impact, in particular when using types that are too large for inline storage inside QVariant (causing allocations).

More preprocessor magic

Another idea could be to use more elaborate preprocessor constructs that allow for iteration over all properties. The Boost.Preprocessor library has the building blocks for this. From experience in an old pre-C++11 project attempting to catch SQL errors at compile time this works but doesn’t really lead to a nice syntax nor easily maintainable code.

A clever overloading trick from Verdigris

The solution I ended up using is inspired by Woboq’s Verdigris. The basic idea is that each property macro generates a part of the comparison function only, the comparison for its property and a call to the comparison function for the previous property. The chaining is done by overloading on a template type that essentially describes a numerical value by inheritance. A little constexpr helper functions allows us to determine the index of a property at compile time. Olivier describes this in more detail in his blog post about Verdigris implementation details.

The resulting code for KItinerary can be found here. It’s worth noting that while this might look inefficient due to the many function calls, this is all inline code in a single translation unit, so in an optimized build this ends up essentially as the hand-written comparison function would look like.

Language support?

Would it make sense to have C++ support something like bool operator==(const T&) const = default, that is let the compiler generate the implementation for us, as it can for a number of other member functions? Proposals for such a language extension exist.

There’s a bigger conceptual problem though, that one runs immediately into once the comparison operator is implemented: the semantics of comparing things. Here are a few examples:

  • Floating point numbers: how close together is “equal” depends on what those numbers represent, in my case of geo coordinates anything within a few meters is certainly more than enough. And there is the little detail that NAN does not compare equal to itself, which isn’t what KItinerary needed either, as NAN is its indicator for “value not set”.
  • QString: here the default equal comparison doesn’t distinguish between null and empty strings. That’s probably very often what you’d expect, unless you put special semantics on that distinction, such as in the NAN case above.
  • Date/time values: two QDateTime instances compare equal if they refer to the same point in time, not if they represent exactly the same information (e.g. time specified with an UTC offset vs a full IANA timezone). For KItinerary timezones are a very crucial information, so the default semantic doesn’t cut it there.

An all-or-nothing approach for compiler-generated comparison operator implementations means it’s not a viable option in case one needs more control over the semantics. That of course does not mean it is useless, but it does mean the alternative implementation techniques remain valid either way.

text KDE Applications 18.12 branches created
Fri, 09 Nov 2018 22:31:23 GMT

Make sure you commit anything you want to end up in the 18.12 release to them

We're already past the dependency freeze.

The Freeze and Beta is this Thursday 15 of November.

More interesting dates
November 29: KDE Applications 18.12 RC (18.11.90) Tagging and Release
December 6: KDE Applications 18.12 Tagging
December 13: KDE Applications 18.12 Release