October 18, 2018

Kubuntu 18.10 has been released, featuring the beautiful Plasma 5.13 desktop from KDE.

Codenamed “Cosmic Cuttlefish”, Kubuntu 18.10 continues our proud tradition of integrating the latest and greatest open source technologies into a high-quality, easy-to-use Linux distribution.

The team has been hard at work through this cycle, introducing new features and fixing bugs.

Under the hood, there have been updates to many core packages, including a new 4.18-based kernel, Qt 5.11, KDE Frameworks 5.50, Plasma 5.13.5 and KDE Applications 18.04.3

Kubuntu has seen some exciting improvements, with newer versions of Qt, updates to major packages like Krita, Kdeconnect, Kstars, Peruse, Latte-dock, Firefox and LibreOffice, and stability improvements to KDE Plasma. In addition, Snap integration in Plasma Discover software center is now enabled by default, while Flatpak integration is also available to add on the settings page.

For a list of other application updates, upgrading notes and known bugs be sure to read our release notes:


Download 18.10 or read about how to upgrade from 18.04.

Additionally, users who wish to test the latest Plasma 5.14.1 and Frameworks 5.51, which came too late in our release cycle to make it into 18.10 as default, can install these via our backports PPA. This represents only the 1st initial bugfix release of Plasma 5.14, with 4 more to be released in the coming months, so early adopters should be aware that there may more bugs to be found (and reported).

Hace un par de semanas que los desarrolladores actualizaron KDE Neon a 18.04 LTS Bionic Beaver, la última versión estable y de soporte extendido de Ubuntu. Una vez comprobado que el salto ha sido un éxito y por no dividir el esfuerzo de los escasos desarrolladores que cuenta el proyecto, ayer fue anunciado que KDE Neon finaliza su soporte a equipos con Xenial 16.04. Una noticia esperada y que deja completamente definida el ciclo de vida de la no-distribución KDE más innovadora que puedes tener en tu PC.

KDE Neon finaliza su soporte a equipos con Xenial 16.04

El anuncio oficial es escueto, como suelen se los anuncios de los desarrolladores y dice así:

“Las actualizaciones a 18.04 están funcionando bien, pero mantener el doble de arquitecturas está afectando nuestro tiempo y el equipo de empacadores de cobayas. La base de KDE Neon en 16.04 (Xenial) llegará al final de la vida el lunes. Actualice a la base 18.04 para continuar recibiendo actualizaciones.”

Así que, si tienes KDE Neon y te aparece una ventana como esta, recomendamos que se actualice todo el sistema. Yo llevo con una semana con la base de Ubuntu 18.04 LTS Bionic Beaver y he tenido algunos problemas menores pero en realidad nada que me impidiera utilizar mi portátil.

KDE Neon finaliza su soporte a equipos con Xenial 16.04

Más información (bueno, básicamente la misma pero en inglés): KDE Neon

Disponible Plasma 14.1

Aprovecho la entrada para anunciar que está ya disponible para su descarga la última versión del escritorio Plasma de la Comunidad KDE que fue lanzado el pasado martes 16 de octubre.

Como sabréis, este tipo de actualizaciones únicamente nos proporcionan (que no es poco) soluciones a los bugs encontrados en esta semana de vida del escritorio y mejoras en las traducciones.

Es por tanto, una actualización 100% recomendable para todos los usuarios de este fabuloso producto fruto del trabajo de algunos miembros de la Comunidad KDE.


In the last episode of this series we discussed QAbstractItemModel::checkIndex().

QAbstractItemModel::checkIndex() is a function added in Qt 5.11 that allows developers of model classes to perform some validity checks on the QModelIndex objects passed to the model; specifically, on the indices passed to the APIs that model classes need to implement (rowCount(), columnCount(), data, setData(), etc.).

These validity checks can be very useful when developing (and debugging) the model itself, or when using a complicated stack of models and proxy models.

However, by its nature, checkIndex() will check just the one index passed to it. It is unable to perform consistency checks on the model “as a whole”. For instance, for a given index, a model’s reimplementation of hasChildren() must be consistent with the values returned by rowCount() and columnCount().

Enter QAbstractItemModelTester

QAbstractItemModelTester is a new class in Qt 5.11 which helps to test item models. It complements checkIndex() by checking the consistency of the entire model from the point of view of a user of the model (like a view).

(Technically speaking, it’s not really new: Qt has had a private class called ModelTest amongst its own autotests for years; ModelTest‘s usecase is the same as QAbstractItemModelTester. For Qt 5.11 I’ve took ModelTest, cleaned it up, renamed it to QAbstractItemModelTester and added it as public API in the QtTest module.)

QAbstractItemModelTester is simple and immediate to use: just create an instance, and pass to its constructor the model that needs to be tested, like this:

QAbstractItemModelTester *tester = new QAbstractItemModelTester(modelToTest);
// keep the tester object around; it will run a series of tests on modelToTest

QAbstractItemModelTester will then automatically perform a series of non-destructive checks on the model. These checks are aimed at verifying the model’s overall consistency; they will verify that the (many) function of the QAbstractItemModel API are always coherent, and will not confuse anyone using the model (like a view, or a proxy model).

Furthermore, QAbstractItemModelTester will also listen to the signals emitted by the model to test; an emission triggers further validation checks, for instance emitting that a row has been added to the model will make tester verify that the row count has been increased by exactly 1.


As an example, let’s consider this very simple model class (a list model of strings):

class StringListModel : public QAbstractListModel {
    using QAbstractListModel::QAbstractListModel;

    int rowCount(const QModelIndex &parent) const override {
        if (parent.isValid())
            return 0;
        return m_strings.size();

    QVariant data(const QModelIndex &index, int role) const override {
        Q_ASSERT(checkIndex(index, QAbstractItemModel::CheckIndexOption::IndexIsValid));
        if (role != Qt::DisplayRole)
            return {};
        return m_strings[index.row()];

    // appends the string at the end of the model
    void appendString(const QString &string) {
        beginInsertRows(QModelIndex(), m_strings.size(), m_strings.size() + 1);

    QStringList m_strings;

The implementation of the model is straightforward: since it’s a list model, only rowCount() and data() need to be implemented. Our model also has a third function (appendString()) that allows the application code to insert a new string into the model, specifically, at the very end.

Let’s focus on this very last function. When inserting new rows into a model, we are supposed to notify the views about the change. QAbstractItemModel’s documentation tells us to use a “transactional” approach: we need to call beginInsertRows() before inserting, perform the insertion, then call endInsertRows().

The parameters to beginInsertRows() describe how many new rows are being inserted, and at which position (the documentation discusses all the details); in our case, we are adding exactly one row at the very end of the model, so we pass m_strings.size() as the position at which the new row will appear.

The third parameter is however wrong: it’s basically stating that we are going to add two rows at the end of the model, while we’re actually adding only one. If we read the documentation carefully, we notice that the parameter shall indicate the index of the last row being added; since we’re adding only one, the index of the last row being added is the same as the first row being added. In order words: the second and third parameter of beginInsertRows() should be identical, like this:

        // correct call: adds 1 row, at position m_strings.size()
        beginInsertRows(QModelIndex(), m_strings.size(), m_strings.size());

These sort of mistakes (in the end, an off-by-one error) can cause lots of troubles: for instance, persistent model indexes start pointing to the wrong data, proxy models get corrupted, and so on.

If we use our model into a QAbstractItemModelTester, we get a notification that there is something wrong going on. For instance, given this setup:

    auto model = new StringListModel;
    auto tester = new QAbstractItemModelTester(model, 

Sometime later, when appendString() is called, QAbstractItemModelTester will detect the mismatch between the rows we are promising we are adding to the model, and the ones we are actually adding to the model. Since the tester object is set to Warning mode it will print a warning on the console, like this:

FAIL! Compared values are not the same:
   Actual (model->rowCount(parent)) 1
   Expected (c.oldSize + (end - start + 1)) 2

We can then use ordinary debugging tools (e.g. a debugger with a breakpoint) to debug what condition caused this warning. We will then notice that the call stack leading to the warning starts in our appendString() function, so we need to double check it and figure out what’s going on in there.

Lastly, note the calls to checkIndex() in the model’s functions that implement the QAbstractListModel API (by overriding rowCount() and data()). QAbstractItemModelTester and checkIndex are meant to complement each other, as the former tests the entire model, while the latter is used to validate the model indexes passed to the various functions.

Reporting failures

In case some of the checks fail, QAbstractItemModelTester has three different ways of reporting the failure to the developer, selectable via an argument to the constructor:

  • By default, QAbstractItemModelTester uses the QtTest failure report mode: failures are reported through the QtTest’s logging mechanisms. This report mode is suitable if we are using QAbstractItemModelTester in a test driven by the QtTest framework, for instance when building unit tests for our model class; a problem in our model will result in the current test function being marked as failing.
  • QAbstractItemModelTester is also usable outside unit tests driven by QtTest. By specifying the Warning failure mode, QAbstractItemModelTester will print a warning statement in the qt.modeltest logging category.
  • Finally, the Fatal failure mode causes the application to crash immediately. In this mode, if a check fails, QAbstractItemModelTester is going to call qFatal() passing a string with a textual description of the error.

No matter which failure mode is set, QAbstractItemModelTester will print debug information about our model in the aforementioned qt.modeltest logging category, showing what kind of changes were detected by the tester class and what sorts of checks are being run. Sometimes this can be useful in order to track down bugs.

Note that this debug output needs to be explicitly enabled by the developer, for instance by setting the QT_LOGGING_RULES environment variable to contain the string qt.modeltest.debug=true. (For more information on Qt’s logging categories, see here).


It is important to note that QAbstractItemModelTester will never perform destructive tests on a model (set new data, insert/remove rows and columns, and so on). This allows developers to safely use the tester in all conditions, including having it enabled in a full build of the application. This way models can be tested in real-world conditions, using actual data, as well as in long-running scenarios (which maybe are required to trigger some bug).

On the other hand, in order to thoroughly test a custom model, we may need to write checks for destructive changes. Since only the developer knows the exact behaviour of a model that undergoes a modification, the developer is supposed to write dedicated unit tests, thus complementing the tests done by QAbstractItemModelTester.

Finally: as I wrote in the last blog post, I believe that the model/view APIs in Qt have a narrow contract: one should never attempt to pass invalid data to a model (e.g. a model index out of range). QAbstractItemModelTester honours this, and will never attempt any illegal operation on a model. If for some reason you need to give your model a wide contract and want to test that contract, further tests (outside QAbstractItemModelTester) are needed.

That’s it for now for now, but stay tuned for more contributions to Qt!

The post New in Qt 5.11: improvements to the model/view APIs (part 2) appeared first on KDAB.

October 17, 2018

Upgrades to 18.04 are working well but maintaining twice as many builds as normal is taking its toll on our time and team of guinea pig packagers. Neon on 16.04 (xenial) base will reach End of Life on Monday.  Please update to 18.04 base to continue receiving updates.

We will be holding a Bug Day on October 20th, 2018, focusing on Konsole. 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!

Como estaba previsto en el calendario de los desarrolladores, ayer martes 16 de octubre la Comunidad KDE ha comunicado que ha sido lanzada la primera actualización de Plasma 5.14. Una noticia que aunque es esperada y previsible es la demostración palpable del alto grado de implicación de la Comunidad en la mejora continua de este gran pedazo de Software Libre.

Lanzada la primera actualización de Plasma 5.14

No existe Software creado por la humanidad que no contenga errores. Es un hecho incontestable y cuya única solución son las actualizaciones. Es por ello que en el ciclo de desarrollo del software creado por la Comunidad KDE se incluye siempre las fechas de las actualizaciones.

De esta forma, el martes 16 de octubre se lanzó la primera actualización de Plasma 5.14, la cual solo trae (que no es poco) soluciones a los bugs encontrados en esta semana de vida del escritorio y mejoras en las traducciones.

Es por tanto, una actualización 100% recomendable.

Más información: KDE.org

Las Novedades de Plasma 5.14

A modo de recordatorio. La versión definitiva de Plasma 5.14 fue publicada el 9 de octubre y ha llegado cargada de novedades. Ya dediqué un artículo íntegro a las mismas pero si queréis leer un resumen rápido de las misma, aquí las tenéis.

  • Nuevo plasmoide para controlar las pantallas conectadas al sistema, muy útil para las presentaciones.
  • Mejor compatibilidad con LibreOffice.
  • El plasmoide de la gestión de redes trabaja de nuevo con túneles SSH VPN.
  • Continuas mejoras en Wayland.
  • Siguen los retoques en las Preferencias del Sistema.
  • Pequeños ajustes en la pantalla de bloqueo y de autentificación presentadas en Plasma 5.13
  • Mejoras en el gestor de aplicaciones Discover.
  • Nuevo fondo de pantalla.

Lanzada la primera actualización de Plasma 5.14

  • Múltiples mejoras en Discover como:
    • Implementación de fwupd, que permite actualizar el firmware del ordenador.
    • Implementados también los canales del Snap.
    • Ahora Discover puede mostrar y ordenar aplicaciones por fecha de publicación.
    • Ahora se pueden ver las dependencias de un paquete de aplicación.

    Y, como siempre, un aluvión de pequeños errores corregidos y optimizaciones de rendimiento.

October 16, 2018

Los desarrolladores de KDE siguen mejorando todo aquello relacionado con KDE y su escritorio Plasma. Y la forma más adecuada de hacerlo es mejorando su motor, esto es, realizando la actualización de octubre del 2018 de KDE Frameworks, es decir, la versión 5.51.

Actualización de octubre del 2018 de KDE Frameworks, el motor de Plasma

Actualización de octubre del 2018 de KDE Frameworks, el motor de PlasmaA pesar de que para los usuarios corrientes esta noticia sea algo confusa, el desarrollo de KDE Frameworks tiene repercusiones directas en él a medio y largo plazo. No hay que olvidar que las mejoras de estas herramientas facilita el desarrollo del Software de la Comunidad KDE, proporcionándonos las herramientas y aplicaciones que utilizamos día a día.

Ayer, 15 de octubre de 2018 fue lanzada KDE Frameworks 5.51, la nueva revisión del entorno de programación sobre el que se asienta Plasma 5, el escritorio GNU/Linux de la Comunidad KDE, y las aplicaciones que se crean con para él. Este KDE Frameworks facilita muchísimo la creación de software para el moderno ecosistema actual de la Comunidad KDE.

Hay que recordar que los desarrolladores de KDE decidieron lanzar actualizaciones mensuales de este proyecto y lo están cumpliendo con puntualmente. La idea es ofrecer pocas pero consolidadas novedades, a la vez que se mantiene el proyecto evolucionando y siempre adaptándose al vertiginoso mundo del Software Libre.

Más información: KDE

¿Qué es KDE Frameworks?

Para los que no lo sepan, KDE Frameworks añade más de 70 librerías a Qt que proporcionan una gran variedad de funcionalidades necesarias y comunes, precisadas por los desarrolladores, testeadas por aplicaciones especí­ficas y publicadas bajo licencias flexibles. Como he comentado, este entorno de programación es la base para el desarrollo tanto de las nuevas aplicaciones KDE y del escritorio Plasma 5.

Actualización de julio del 2018 de KDE Frameworks

Aquí podéis encontrar un listado con todos estos frameworks y la serie de artículos que dedico a KDE Frameworks en el blog,

Recuerda que puedes ver una introducción a Frameworks 5.0 en su anuncio de lanzamiento.

Sebastian Labi ha sido invitado para presentar Krita en el Laboratorio de herramientas de software libre de la Universidad de La Plata. Hablará sobre ilustración digital y usará Krita para dar una demostración de cómo usar Krita para el campo de la Ilustración Digital.

El SLAD- FBA (Software libre para Arte y diseño) es una nueva unidad de de investigación y formación en la Facultad de Bellas Artes que promueve el conocimiento y uso del software libre en la capacitación académica de la Universidad de La Plata.

El evento tendrá lugar el Miércoles 31 de Octubre a las 14:00.

Sebastian Labi has been invited to present Krita in the laboratory of Free Software tools of the Unversity of La Plata.  He will talk about digital illustration and using Krita, as well as giving a hands-on demonstration of Krita. SLAD – FBA | Free Software for Art and Design is a new unit of research and training at the Faculty of Fine Arts which promotes knowledge and use of Free Software in the academic training of the University of La Plata.

SLAD is a new research and teaching group in the Faculty of Fine Art in La Plata University which wants to promote systemtatic and sustained knowledge on how Art and Open Source interacts in an academic setting.

The meeting will be on Wednesday October 31st at 14:00.

The third day of LaKademy 2018 was my last day participating on the event. During October 13th, we started the day with a promo reunion. This reunion was done to discuss about some plans and actions for the Latin American KDE community over the next year. Some decisions were made and topics were discussed involving … Continue reading LaKademy 2018 – Third and Fourth Days (October 13th and 14th)

October 15, 2018

We’re glad to announce that we received donation of 100,000 USD, which is part of 300,000 USD offered to our KDE organization. Quite appropriate for a birthday present, as the KDE project just turned 22 this last weekend! It’s true recognition for KDE as one of the world’s largest open source project.

More information: KDE e.V. receives a sizeable donation from Handshake Foundation.


Could you tell us something about yourself?

Hi, my name is Sira Argia. I am a digital artist who uses FLOSS (Free/Libre Open Source Software) for work. I come from Indonesia, Sanggau Regency, West Kalimantan.

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

I don’t think that I am professional in my digital painting work because there’s so much things I need to learn before I achieve something that can be called “professional”. At the beginning, it’s just a hobby. I remember my first painting artwork was very bad, haha. But now I think my artworks are far better than the first. I believe in “practice makes perferct”.

What genre(s) do you work in?

I call it “semi realistic” art style. I usually use anime/manga or Disney style for the character’s face look-alike and use realistic shading a little bit.

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

David Revoy and Sara Tepes. They inspire and help me a lot with their tutorials.

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

I started in 2014-2015. I used the traditional method (with pencil and paper) and traced it with Inkscape.

Then 2016. That’s the first time I tried digital painting because I just bought my first graphic tablet that time.

What makes you choose digital over traditional painting?

I am not in the position that I have to choose between digital or traditional painting, because if there’s a teacher, I really need to learn all of them. The reasons why I am doing digital painting at this moment is that iI can find tutorials everywhere on the internet and it’s easy to practice because I have the monitor and the digital pen for digital painting. Besides, I am working as a freelance artist and every client asks for digital raw files.

How did you find out about Krita?

2014 is the year that I first started to try Linux on my laptop, and then I knew that Windows programs don’t run perfectly on Linux even using “wine”. My curiosity about Linux and the alternative programs led me to Krita. The more time I spent with Linux, the more I fell in love with it. And finally I thought that “I’ll choose Linux as a single OS on my laptop and Krita as a digital painting program for work someday after I get my first graphic tablet.”

What was your first impression?

The first Krita that I tried is version 2.9. I followed David Revoy’s blog and youtube channel to learn his tutorials about Krita. I thought at the time that Krita was very laggy for bigger canvas sizes. But I still used it as my favorite digital painting program because I thought that Krita was a powerful program.

What do you love about Krita?

Powerful and Free Open Source Software.

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

I hope Krita will not use so much processor and ram in the future, it always gets to force close when I use many layers in a bigger canvas.

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

I’ve never used other painting programs for a long time except Krita. So I don’t know, Krita has unique features. For example, other programs have something called called “clipping layer” but Krita called it “inherit alpha”.

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

Here’s my character who is called Seira. Still my favourite because this is the first time I didn’t pick any palette colors from the internet and I
started to understand about “source light” in the digital painting.

What techniques and brushes did you use in it?

a. Sketch

I usually begin from the stickman. I thought about pose and the composition at this point. Then I start to draw the naked body from the stickman. That’s the part where I have to draw the anatomy clearly. After that, I start to draw the costume of the character. I am not really good at line art, so I let it become a sketch because for me, it’s just a guide to the next step.

b. Coloring

This is a very important part for me because I need to be clear with the shading, texture of the material, value, etc. For the brushes, the Deevad bundle and the Krita default brush bundle are more than enough.

Where can people see more of your work?


Anything else you’d like to share?

I just want to give a message to the people who see this. “It’s better to use FLOSS (Free/Libre Open Source Software) like Krita for example, than use proprietary software (even worse if you use the cracked software). It’s bad. Really…”

Yesterday was the last day of the developers sprint^Wmarathon, and the last day of the fundraiser. We’re all good and knackered here, but the fundraiser ended at a very respectable 26,426 euros! That’s really awesome, thanks everybody!

We’ve already updated the about box for Krita 4.2 with the names or nicknames of everyone who wanted to be mentioned, and here is the final vote tally:

1 – Papercuts 202
2 – Brush Engine 132
3 – Animation 128
6 – Vector Objects and Tools 73
5 – Layers 59
7 – Text 48
10 – Photoshop layer styles 43
4 – Color Management 29
9 – Resource Management and Tagging 20
8 – Shortcuts and Canvas Input 18

Now we’re going to take a short break, and then it’s rollup our sleeves and get to work!

We are excited to announce that the KDE e.V. received a donation of 300,000 USD from the Handshake Foundation. Quite appropriate for a birthday present, as the KDE project just turned 22 this last weekend!

The Calligra office suite project will
be receiving 100,000 USD.

Of the total donation amount, 100,000 USD will be specifically allocated to pursue the development of the Calligra office suite.

"Handshake is pleased to be able to support KDE's international community of dedicated volunteers and their continued commitment to a free desktop environment with the current release of KDE Plasma 5 and the Calligra office suite", says Rob Myers from the Handshake Foundation.

The fruits of this contribution will soon become visible and available to everyone. Meanwhile, don't hesitate to join the KDE Community and be part of our mission to help everyone protect their privacy and control their digital lives with Free Software.

Stay tuned for more updates, and tell us how you celebrated KDE's 22nd birthday!

It’s time for another digiKam Recipes update. The most visible change in the latest revision is the new book cover. All screenshots were also updated to reflect changes in the current version of digiKam. In addition to the visual tweaks, the latest revision features new content. Continue reading…

October 14, 2018

For quite some time, the KDE e.V. – KDE’s non-profit organization – is listed in the AmazonSmile program. On the AmazonSmile website it says:

AmazonSmile is a website operated by Amazon that lets customers enjoy the same wide selection of products, […]. The difference is that when customers shop on AmazonSmile (smile.amazon.com), the AmazonSmile Foundation will donate 0.5% of the price of eligible purchases to the charitable organizations selected by customers.

In other words, if you do a lot of shopping on Amazon anyways, make sure to start shopping via smile.amazon.de and choose the “KDE e.V.” as organization. This way you financially support the KDE e.V., even without having to pay more. I am posting this here since I know many people who buy things on Amazon several times a week. Feel free to spread the word & happy shopping ��

PS: This is not supposed to be advertisement for Amazon. You can also donate to the KDE e.V. directly.

PPS: It seems the KDE e.V. is only available on German Amazon.

Just as quick info: For some time, there is a sticky thread on r/cpp about who is hiring C++ developers. This thread gets cleaned quarterly, so all the open jobs listed there are likely still open. The same was just started on reddit for r/Qt5: Who’s Hiring Qt Devs – Q4 2018: So if you are looking for either C++ or Qt jobs, this is a good place to have a look at from time to time. When I just looked for r/Qt5, the list was still empty, but this hopefully changes soon, given that the post was added just some hours ago. ��

We fully intended to make a post every day to keep everyone posted on what’s happening here in sunny Deventer, the Netherlands.

And that failed because we were just too busy! I’m triaging bugs even as I’m working on this post, too! We are on track to have fixed about a hundred bugs during this sprint. On the other hand, the act of fixing bugs seems to invite people to test, and then to report bugs, so in the past ten days, there were fifty new reports. That all makes for a very hectic sprint indeed!

All through the week, we all touched many different parts of Krita, sharing knowledge and making everyone of us more all-round when it comes to Krita’s codebase. Remember, people have been working on this code since 1999. Nobody back then expected we’d have millions of users one day!

At the Krita headquarters, one usually cooks for two or three, cooking for eight was a bit of a challenge, but cook we did, for Wolthera, Irina, Boudewijn, Dmitry, Ivan, Jouni, Emmet and Eoin. Let’s go through the days, menu and bugs!

Saturday: Minestrone

On Saturday, we merged Michael Zhou’s Summer of Code work on improving the palette docker and making it possible to save palettes in your .kra project file. Of course, that meant that all through the week we had to fix issues here and there caused by this merge, but that was to be expected. All through the week, using the nightly builds must have been a roller-coaster experience for our testers!

And we got a lot more done, too: Jouni was demonstrating his clone frames and frames cycle feature, Eoin added a global kinetic scrolling feature, where you can pan pretty much every list with the middle-mouse button. That makes Krita much nicer to use on touchscreens.

Sunday: Pasta with tomato sauce

On Sunday, we really got into our stride. Wolthera updated the user manual with all the new features — if you haven’t checked out the manual, do so, we’re quite proud of it! Emmet fixed the color picker tool, which had a bit of trouble showing the correct value for the alpha channel. There were smaller and larger bug fixes, but a very nice new feature was added as well: new contributor Reptorian, after coding a bunch of new blending modes, put his teeth into a larger feature: a symmetric difference mode for the selection tools.

This is not the first time that someone with little or no background in C++ does really useful work for Krita. In fact, it happens all the time, and for this we worked together with Alberto Flores who was working on his very first patch. And he did make it!

Monday: Moussaka

On Monday, we fixed a nasty little bug where the order in which you select layers in the layerbox would influence the order in which layers would be merged. There were fixes to the animation timeline.

The big feature of Monday was making it possible to import SVG files as a vector layer. Originally, and silly enough, an SVG file would be imported as a raster layer when using the layer/import image as layer function.

Dmitry started working on making Krita’s canvas support display scaling properly.: this work would go on all through the week.

Jouni started working on fixing the sound stuttering when playing an animation. That patch is ready to land, and when we released on Thursday, it turns out that this was the thing we got most questions about.

And we fixed bugs…

Tuesday: Honey-braised pork, sesame beans and cabbage in oyster sauce

On Tuesday we did a bunch of bug triaging and assigned bugs to the people present. Then there were crash fixes, python fixes, ui polish… And we also looked into what would be needed to support HDR monitors, but that’s going to be a long slog!

Wednesday: Stuffed bellpeppers

On Wednesday, Dmitry refined the way users can modify and work with selections: now one should hover over the selection border to start moving a selection. And a lot of bugs and crashes were fixed all long day long, but we also started preparing for the release itself, by backporting all the fixes to the 4.1 branch.

Thursday: Dining out at Da Mario, and a release

This was the day we had to redo the release three times! But we did release in the end, with almost fifty bugs fixed.

But there was also fixing being done!

Eoin fixed a bug in the animation curve editor, fixed bugs in the bristle and smudge brushes. Wolthera fixed a regression in the color selector. Turns out that if you replace a division by two with a multiplication by 0.5, you shouldn’t keep dividing it…

Dmitry also pushed the final set of fixes for using display scaling correctly in Krita. That’s another very, very long standing bug finally fixed!

And it’s not just people at the sprint who are busy! Mehmet Salih Çalışkan submitted two patches, one for the text tool, one for the brush editor, and today his patches were pushed. Anna Medonosva was fixing issues with the artistic color selector.

In the afternoon, we went out for a walk and met the Deventer sheep herd, as well as the shepherd.

That evening, none of us cooked, we went out to Da Mario instead to have dinner together with one of the more local supporters of Krita.

Friday: Ajam pedis and sambal goreng beans

Emmett fixed a really hard bug where sometimes when smudging black gets mixed into the color. We’re pretty sure there are more bugs like this in the database, but we’d need some testing done to see which bugs those are. It’s one thing that makes the bugs database such a mess: we have lots of duplicates, but often the fact that they’re duplicates isn’t apparent at all.

Jouni fixed issues with the G’Mic integration, Boudewijn looked into the problem with saving a group layer with a transparency mask to OpenRaster: that needs updating the OpenRaster standard though. But he didn’t waste the entire day, he also fixed loading line end markers for vector lines on Windows and macOS. Ivan fixed macOS-specific issues in the animation timeline.

Later in the afternoon we discussed options to reduce the mess in bugzilla a bit by using a helpdesk system and/or an a question/answer type site. Bugzilla really should only contain bugs, not user support type questions!

Saturday: Runner beans and meatballs with mint sauce

Saturday was our day off. All work and no play and all that sort of thing. We visited a nearby town, called Zwolle. It’s a pretty place, a little larger than Deventer, and it has kept one of its town gates, the Sassenpoort. Previously used as the town’s archive, it’s now and then open to the public, and well worth a visit. Zwolle has been barbaric enough to close its local history museum because it wasn’t turning a profit, but there’s still the Fundatie, a modern art museum, which was showing a smallish exhibition of works by sculptors Giacometti and Chadwick.

And in the evening we went back to hacking. Jouni is this close to fixing audio playback for animations: in fact, it’s ready to be merged!

Sunday: Black pudding with beetroot and stewed pears

And today, while Jouni has already gone back to Finland, we’re back at fixing bugs! But this was one loooong sprint, more of a marathon, and we’re getting a bit frazzled now. Still, there are more bugs to be fixed!

The End

Tomorrow, our marathon coders will wend their way homewards. The fundraiser will end, at the very great amount of 25,000 euros (it’s actually more, because people have also been donating directly through Krita’s bank account, and the website doesn’t count that.). And we will be fixing bugs, and work on achieving that polish and stability that makes all the difference!

It’s been rather quiet when it comes to accessibility in KDE land for a while. But I’m very happy to see some movement and fresh energy, moving in a good direction.

If you’re curious about making our software available to more users, improving it for everyone (for example keyboard usability), now is the time to join. We are talking on the accessibility mailing list. It’s still to early to say what the exact plan will look like, but there will be progress. Thanks to the last Randa meeting, we reached the point where a few things in Plasma do work with a screen reader, enough to let a few brave souls experiment with it. Now we’ll have to structure what needs improvements, I could imaging defining some workflows. Once we have broken down the big goal of making Plasma a joy to use with a screen reader, we’ll have to make sure of a few things for each sub goal:

  • Keyboard navigation needs to work – being blind, using a mouse is often pointless, since you won’t see the pointer. It’s very important that we can do everything with the keyboard. This is of course good for everyone, we all win.
  • The screen reader needs to know what to present to the user – we need to make sure that buttons that only show an icon have an alternative description for example. Some work has been done in this direction, but without user testing, it won’t be polished or even complete.
  • Performance fixes in the accessibility stack – this needs some investigation, some of the implementation in Qt may not be in agreement with what Orca expects.
We will try to coordinate the work starting on the Plasma Accessibility Phabricator board.
I think we really need someone to take on the role of coordinator and help move this forward, listening to users what’s most important and getting developers to spend a little time fixing things. This is really something anyone can help with, and I think we already have some people interested on the list.

The Ubuntu release team have announced a 1st test ISO RC build for all 18.10 flavours.

Please help us test these and subsequent RC builds, so that we can have an amazing and well tested release in the coming week.

As noted below, the initial builds will NOT be the final ones.

Over the next few hours, builds will start popping on the Cosmic Final
milestone page[1] on the ISO tracker.  These builds are not final.
We're still waiting on a few more fixes, a few things to migrate, etc.
I've intentionally not updated base-files or the ISO labels to reflect
the release status (so please don't file bugs about those).

What there are, however, are "close enough" for people to be testing in
anger, filing bugs, fixing bugs, iterating image builds, and testing
all over again.  So, please, don't wait until Wednesday night to test,
testing just before release is TOO LATE to get anything fixed.  Get out
there, grab your favourite ISO, beat it up, report bugs, escalate bugs,
get things fixed, respin (if you're a flavour lead with access), and
test, test... And test.  Did I mention testing?  Please[2] test.


... Adam

[1] http://iso.qa.ubuntu.com/qatracker/milestones/397/builds
[2] Please.

Downloads for RC builds can be found by following the link after clicking through to ‘Cosmic Final’ on the Ubuntu ISO tracker. Please report test case results if you have a Ubuntu SSO account (or are prepared to make one). Feedback can also be given via our normal email lists, IRC, forums etc.

Upgrade testing from 18.04 in installed systems (VM or otherwise) is also a very useful way to help prepare for the new release. Instructions for upgrade can be found on the Ubuntu help wiki.

Ubuntu ISO tracker: http://iso.qa.ubuntu.com/qatracker/
Kubuntu-devel mailing list: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Kubuntu IRC channels: #kubuntu & #kubuntu-devel on irc.freenode.net
Kubuntu 18.10 Upgrade instructions: https://help.ubuntu.com/community/CosmicUpgrades/Kubuntu

Welcome to an even more humongous week in KDE’s Usability & Productivity initiative!

I’d like to specially highlight one very important fix this week: external hard drives are now safely powered off when unmounted. The fix is in KDE Frameworks 5.52, which will be released in approximately three weeks, and I’d like to give a big thanks to Stefan Brüns who fixed it!

Speaking of Stefan, he and Igor Poboiko have been doing an absolutely smashing job fixing Baloo over the past two weeks. A lot of their work is hard to blog about because it’s not immediately user-facing (though I’ve included as much as possible below), but between the two of them, they’ve made an enormous number of improvements to Baloo that should make it work faster and more smoothly in a lot of subtle ways.

But obviously that’s not all; take a look at the rest of the week’s work:

New Features


UI Polish & Improvement

Also, I want to mention that we’re aware of two high-profile issues in Discover that slipped by testing and made it into the 5.14.release:

We apologize for these bugs and we’re working to get them fixed quickly!

One of the reasons why bugs like this squeak through is that we don’t have enough pre-release QA testers. You could be one of them, and next week, your name could be in this list! Just 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.

October 13, 2018

Every new code follows new bugs. During the second day of LaKademy I was more focused on resolution of bugs in the code that I implemented during the first day for KDE Partition Manager. During the afternoon, I decided to start RAID resizing and discussed with Andrius Stikonas on calamares IRC channel about some RAID … Continue reading LaKademy 2018 – Second Day (October 12th)

Static linking has long gone out of fashion, at least on the average Linux desktop distribution. There are however good reasons to still (or again) support this for our frameworks. One is the rise of application bundles (Flatpak, Android APK, AppImage, etc).

Bundles often only contain a single executable, so there is no benefit of sharing a library (at least in most bundle formats, Flatpak is a bit different there). Still we need to ship everything the shared libraries provide, no matter if we need it or not.

Static linking is of course not the magic solution to this, but it’s a fairly generic way of allowing the compiler to drop unused code, reducing the application size. As application bundles are usually updated as a whole, we also don’t benefit from the ability to update shared libraries independently, unlike with a conventional distribution.

Besides application bundles, there are also single process embedded applications that can benefit from static linking, so this is relevant for the effort of bringing KF5 to Yocto. In particular on lower powered embedded devices the startup overhead of dynamic linking can be noticeable.

Build System

In order to make our frameworks usable as static libraries, there’s essentially two areas that might need a few adjustments, build system and code.

On the build system side there’s two things to look at. The first one is to not force libraries to be built as shared libraries and instead allow the user to select this. That is, don’t use the SHARED keyword in the add_library call. Normally CMake would default to static libraries when doing that, but ECM’s KDECMakeSettings changes that for us. To actually build static libraries, you need to set the BUILD_SHARED_LIBS CMake option to OFF (example).

The other aspect that needs attention on the CMake side is how private library dependencies are handled. For shared libraries the consumer doesn’t need to know anything about those as this is encoded in the shared library file. A static library however is just a simple archive of object files, without such meta data, so public and private dependencies are conveyed in the CMake config file to the consumer. This however means that the consumer needs to also look for all private dependencies in order to link against those. That’s done by also listing those in the CMake config file for the static library, next to the public dependencies already listed there (example).

Static Initialization

One rather subtle but far reaching difference to dynamic libraries is how static initialization works. That is, code that is implicitly executed when loading the library (even before the application code is run). Static initialization is used in a number of places:

With dynamic libraries this works on all platforms, with static libraries it doesn’t work in many cases and thus cannot be relied upon anymore. So, we need to change code affected by this.

This usually implies moving code that would run as part of static initialization to a later point in time, e.g. on first use of whatever is initialized. This can be beneficial for startup performance, but we have to be careful to not accidentally move potentially expensive operations on hot paths at runtime instead then (basic example, more exotic example).

Another potential place for such initialization code would be single entry points in to the library, such as QCoreApplication is for QtCore. The last resort approach is an explicit init() function as discussed here. That however changes API from a user point-of-view, so I’d avoid that where possible.

Identifying all affected code is not always straightforward. Broad unit test coverage provides great value there, but ultimately you probably want to look at all method calls in the .init_array section of the dynamic library (or the corresponding non-ELF counter-part on other platforms), e.g. using a tool like ELF Dissector. Not everything in there is automatically a problem, but all problems will be in there.

Further Challenges

Another thing that doesn’t make much sense in a statically linked setup is usage of dlopen (or its counter-parts on other platforms), most commonly used by plug-in systems. Qt has a solution for statically linking plug-ins as part of QPluginLoader. That can be a bit of work to use in practice as all plugins need to be consumable as static libraries by the application too, and need manual Q_IMPORT_PLUGIN statements, but at least it’s nothing that requires creative solutions.

Static linking of course is not the complete solution to being able to create single application bundles, frameworks relying on multi-process architectures, daemons, IPC, etc need to be addressed independently of that still.

One problem we don’t have for KDE applications at least are license issues caused by static linking, that’s left to proprietary users ;)

KDE members in the impressive foyer at Escola del Treball

Meeting with Pablo of Catalan Generalitat distro Linkat

Last week developers from the KDE neon and Plasma teams visited Barcelona. We were there to meet with some KDE software projects we had heard about in the Catalan government and schools. Aleix Pol lives locally and works on Plasma and Discover. He invited Plasma release manager and KDE neon developer Jonathan Riddell, KDE neon continuous integration master Harald Sitter, and hardware enablement guru Rohan Garg to meet the teams evaluating our software and supporting our users.

We first met Pablo who runs the Linkat project for the Catalan government. Linkat is a Linux distribution they offer to schools, and it currently runs lightweight, simple desktop environments. As Plasma 5 now tends to use as little or less memory and resources than many lightweight Linux desktops, the Linkat team is interested in trying it. We met with the officials from the education department and discussed accessibility needs, looking at Mycroft for voice control and integrating with phones using KDE Connect.

The Escola del Treball is looking for
ways to keep their IT infrastructure
current, while at the same time
cutting costs

The next day we visited the largest technical school in Catalunya, the Escola del Treball (school of the workers). Within their impressive Gaudí-inspired building, they run a few thousand computers on which they are trying to reduce the costs. They showed us the setup they had developed using thin clients with a simple Atom computer or Raspberry Pi. The thin clients use a remote desktop protocol to talk to virtual machines on a central server. The technically-minded teachers can customize what's running on the virtual machine with a range of distributions and operating systems available. Their server has hosted over 3000 virtual machine images just on the trial computers, all for the individual use cases of the teaching staff. Unlike with proprietary setups, this means they do not have to ask for a budget to install software.

They discussed some problems their virtual machine software was having with Plasma and tested some fixes made by Aleix. Rohan was also interested in finding the best machines they could use for their thin clients.

In the evening, we met with developer Angel Docampo and talked about the deployment he worked on for the Ajuntament (city council) of Barcelona. The Ajuntament is also interested in moving towards Free Software on their computers. This deployment is based on Kubuntu, and it is currently in trial by about 30 employees. Angel reported that they are happy with the setup; however, taking it further will likely depend on the politicians‘ will to drive the change forward.

As we were about to leave, we learned about a project called openUAB at the Autonomous University of Barcelona. They are making a KDE neon-based system for their own uses. We expect to find out more about this project after Aleix meets with them in the upcoming weeks.

This was an exciting trip that opened our eyes to the increasing number and variety of users and use cases of KDE software. The insights we collected will help us deliver better software, and strengthen the bonds between our community and the rest of the world.

October 12, 2018

Kdenlive 18.08.2 is out bringing usability improvements and a crash fix. The Windows version is also becoming more stable with every release and this version brings fixes to the translation installation and the introduction of a crash report.

In other news, the Refactoring is moving steadily ahead and we will release a wider test beta version soon, stay tuned. Also the refactoring branch is now building automatically on KDE’s automated integration system (CI), and all the regressions tests pass. This means that after each change to the source code, the CI will run the tests to check that no regression happens. On the sysadmin front we are cleaning up our bug tracker in preparation for the 18.12 release.

Bug fixes:

  • Improve missing luma detection (region transition) – fixes project crash. Commit.
  • Home/End now also seek in clip monitor. Commit.
  • Update AppData for upcoming release. Commit.
  • Windows crash reports. Commit.
  • Update authors. Commit.
  • Fix double clicking a title clip in bin tries to rename instead of opening the title dialog. Commit.

Get it:




LaKademy 2018 has started! It is happening in the city of Florianópolis in Brazil. It is being a nice opportunity for me to meet some other KDE contributors from Latin America. We are discussing ideas for KDE in Latin America and everybody is working on something related to the community. The event will continue until … Continue reading LaKademy 2018 – First Day (October 11th)

October 11, 2018

Coming hot on the heels of Krita 4.1.3, which had an unfortunate accident to the TIFF plugin, we’re releasing Krita 4.1.5 today! There’s a lot more than just that fix, though, since we’re currently celebrating the last week of the Krita Fundraiser by having a very productive development sprint in Deventer, the Netherlands.

There are some nice highlights as well, like much improved support for scaling on hi-dpi or retina screens. But here’s a full list of more than fifty fixes:

  • Associate Krita with .ico files
  • Auto-update the device pixel ration when changing screens
  • Disable autoscrolling for the pan tool
  • Disable drag & drop in the recent documents list BUG:399397
  • Disable zoom-in/out actions when editing text in rich-text mode BUG:399157
  • Do not add template files to recent documents list BUG:398877
  • Do not allow creating masks on locked layers. BUG:399145
  • Do not close the settings dialog when pressing enter while searching for a shortcut BUG:399116
  • Fill polyline shapes if some fill style was selected BUG:399135
  • Fix Tangent Normal paintop to work with 16 and 32 bit floating point images BUG:398826
  • Fix a blending issue with the color picker when picking a color for the first time BUG:394399
  • Fix a problem with namespaces when loading SVG
  • Fix an assert when right-clicking the animation timeline BUG:399435
  • Fix autohiding the color selector popup
  • Fix canvas scaling in hidpi mode BUG:360541
  • Fix deleting canvas input settings shortcuts BUG:385662
  • Fix loading multiline text with extra mark-up BUG:399227
  • Fix loading of special unicode whitespace characters BUG:392710
  • Fix loading the alpha channel from Photoshop TIFF files BUG:376950
  • Fix missing shortcut from Fill Tool tooltip. BUG:399111
  • Fix projection update after undoing create layer BUG:399575
  • Fix saving layer lock, alpha lock and alpha inheritance. BUG:399513
  • Fix saving the location of audio source files in .kra files
  • Fix selections and transform tool overlay when Mirror Axis is active BUG:395222
  • Fix setting active session after creating a new one
  • Fix showing the color selector popup in hover mode
  • Fix the ctrl-w close window shortcut on Windows BUG:399339
  • Fix the overview docker BUG:396922, BUG:384033
  • Fix the shift-I color selector shortcut
  • Fix unsuccessful restoring of a session blocking Krita from closing BUG:399203
  • Import SVG files as vector layers instead of pixel layers BUG:399166
  • Improve spacing between canvas input setting categories
  • Make Krita merge layers correctly if the order of selecting layers is not top-down. BUG:399146
  • Make it possible to select the SVG text tool text has been moved inside an hidden group and then made visible again BUG:395412
  • Make the color picker pick the alpha channel value correctly. BUG:399169
  • Prevent opening filter dialogs on non-editable layers. BUG:398915
  • Reset the brush preset selection docker on creating a new document BUG:399340
  • Support fractional display scaling factors
  • Update color history after fill BUG:379199



Note for Windows users: if you encounter crashes, please follow these instructions to use the debug symbols so we can figure out where Krita crashes.


(If, for some reason, Firefox thinks it needs to load this as text: to download, right-click on the link.)

When it is updated, you can also use the Krita Lime PPA to install Krita 4.1.5 on Ubuntu and derivatives. We are working on an updated snap.


Note: the touch docker, gmic-qt and python plugins are not available on OSX.

Source code


For all downloads:


The Linux appimage and the source tarball are signed. You can retrieve the public key over https here:
. The signatures are here (filenames ending in .sig).

Support Krita

Krita is a free and open source project. Please consider supporting the project with donations or by buying training videos or the artbook! With your support, we can keep the core team working on Krita full-time.

Me and Tarek

It was really nice working with Tarek on GSoC 2018 project with KDE. Tarek did a good job supporting new export tool for digiKam so users can upload their local images to more web services. check his work report here

The photo was taken by the art awesomeness symbol Heba Attwa

Clazy 1.4 has been released and brings 10 new checks.

Clazy is a clang compiler plugin which emits warnings related to Qt best practices. We’ll be showing Clazy at Qt World Summit in Boston, Oct 29-30, where we are a main Sponsor.

You can read more about it in our previous blog posts:

Today I’ll go through all 10 new warnings, one by one. For other changes, check the complete 1.4 Changelog. So let’s start. I’ve ordered them according to my personal preference, starting with the ones that have helped me uncover the most bugs and finishing with some exotic ones which you’ll rarely need.

1. skipped-base-method

Warns when calling a method from the grand-base class instead of the direct base class one.


class MyFrame : public QFrame
    bool event(QEvent *ev) override
        // warning: Maybe you meant to call QFrame::event() instead [-Wclazy-skipped-base-method]
        return QWidget::event(ev); 

The motivation came after hitting bugs when overriding QObject::event() and QObject::eventFilter(). I would suggest always using this check and annotating your legit cases with // clazy:exclude=skipped-base-method, to make your intention clear. The same way you would comment your fallthroughs in switch statements.

This check might get removed in the future, as in the end it’s not specific to Qt and clang-tidy recently got a similar feature.

2. wrong-qevent-cast

Warns when a QEvent is cast to the wrong derived class via static_cast.


switch (ev->type()) {
    case QEvent::MouseMove:
        auto e = static_cast<QKeyEvent*>(ev);

Only casts inside switch statements are verified.

3. qhash-with-char-pointer-key

Finds cases of QHash<const char *, T>. It’s error-prone as the key is just compared by the address of the string literal, and not the value itself.

This check is disabled by default as there are valid use cases. But again, I would suggest always using it and adding a // clazy:exclude= comment.

4. fully-qualified-moc-types

Warns when a signal, slot or invokable declaration is not using fully-qualified type names, which will break old-style connects and interaction with QML.

Also warns if a Q_PROPERTY of type gadget is not fully-qualified (Enums and QObjects in Q_PROPERTY don’t need to be fully qualified).


namespace MyNameSpace {

    struct MyType { (...) };

    class MyObject : public QObject
        Q_PROPERTY(MyGadget myprop READ myprop); // Wrong, needs namespace
        void mySignal(MyType); // Wrong
        void mySignal(MyNameSpace::MyType); // OK

Beware that fixing these type names might break user code if they are connecting to them via old-style connects, since the users might have worked around your bug and not included the namespace in their connect statement.

5. connect-by-name

Warns when auto-connection slots are used. They’re also known as “connect by name“, an old and unpopular feature which isn’t recommended. Consult the official documentation for more information.

These types of connections are very brittle, as a simple object rename would break your code. In Qt 5 the pointer-to-member-function connect syntax is recommended as it catches errors at compile time.

6. empty-qstringliteral

Suggests to use an empty QString instead of an empty QStringLiteral. The later causes unneeded code bloat.

You should use QString() instead of QStringLiteral() and QString("") instead of QStringLiteral("").

7. qt-keywords (with fixit)

Warns when using Qt keywords such as emit, slots, signals or foreach.

This check is disabled by default. Using the above Qt keywords is fine unless you’re using 3rdparty headers that also define them, in which case you’ll want to use Q_EMIT, Q_SLOTS, Q_SIGNALS or Q_FOREACH instead.

This check is mainly useful due to its fixit to automatically convert the keywords to their Q_ variants. Once you’ve converted all usages, then simply enforce them via CONFIG += no_keywords (qmake) or ADD_DEFINITIONS(-DQT_NO_KEYWORDS) (CMake).

8. raw-environment-function

Warns when putenv() or qputenv() are being used and suggests the Qt thread-safe equivalents instead. This check is disabled by default and should be enabled manually if thread-safety is important for you.

9. qstring-varargs

This implements the equivalent of -Wnon-pod-varargs but only for QString.

This check is only useful in cases where you don’t want to enable -Wnon-pod-varargs. For example on projects with thousands of benign warnings (like with MFC’s CString), where you might only want to fix the QString cases.

10. static-pmf

Warns when storing a pointer to a QObject member function and passing it to a connect statement. Passing such variable to a connect() is known to fail at runtime when using MingW.

You can check if you’re affected by this problem with the following snippet:

static auto pmf = &QObject::destroyed;
if (pmf == &QObject::destroyed) // Should be false for MingW

Conclusion and thoughts for version 1.5

Clazy has matured and it’s getting increasingly difficult to come up with new ideas for checks. For version 1.5 I won’t be focusing in writing new warnings, but instead figuring out how to organize the existing ones.

This project has come a long way, there’s now 77 checks and I feel the current classification by false-positive probability (levels 0, 1, 2, 3) is not scaling anymore. I will try to organize them by categories (bug, performance, readability, containers, etc), which would be orthogonal to levels and hopefully also answer the following questions:

  • What’s the absolute sub-set of checks that every project should use ?
  • Which ones should abort the build if triggered (-Werror style) ?
  • How to make clazy useful in CI without getting in the way with annoying false-positives ?
  • How to let the user configure all this in an easy way ?

But of course, if you know of any interesting check that wouldn’t cost me many days of work please file a suggestion or catch me at #kde-clazy (freenode) and it might make it to the next release.

The post Clazy 1.4 released appeared first on KDAB.

We are happy to announce the release of Qt Creator 4.8 Beta!


Generic Programming Language Support

In Qt Creator 4.8 we’ll introduce experimental support for the language server protocol. For many programming languages there is a “language server” available, which provides IDEs with a whole lot of information about the code, as long as they support communicating via the protocol.

This means that by providing a client for the language server protocol, Qt Creator gets (some) support for many programming languages “for free”. Currently Qt Creator supports code completion, highlighting of the symbol under cursor, and jumping to the symbol definition, as well as integrates diagnostics from the language server. Highlighting and indentation are still provided by our generic highlighter, since they are not provided via the language server protocol.

To use a language server, you first need to enable the LanguageClient plugin in Help > About Plugins (Qt Creator > About Plugins on macOS). Then add the server in Tools > Options > Language Client, choosing a MIME type (glob patterns are in the works), server executable and any required command line arguments. The server is automatically started – just open a file of the corresponding type and start hacking :).

Note that the client is mostly tested with Python. There will most probably be one or the other issue when you try your most favorite language. Also, we currently do not support language servers that require special handling. If you find issues, we are happy to receive bug reports, preferably including Qt Creator console output with the environment variable  QT_LOGGING_RULES=qtc.languageclient.*=true set.

C++ Support

On the C++ side we added some experimental features.

Compilation Database Projects

Open a compilation database as a project purely for editing and navigating code. A compilation database is basically a list of files and the compiler flags that are used to compile them. Some build systems and tools are able to generate such databases for use in other tools. In Qt Creator it feeds the code model with the necessary information for correctly parsing the code. Enable the plugin CompilationDatabaseProjectManager to try it.

Clang Format Based Indentation

Does auto-indentation via LibFormat which is the backend used by Clang Format. Enable the plugin ClangFormat to try it.

Cppcheck Diagnostics

Integrates diagnostics generated by the tool Cppcheck into the editor. Enable the plugin Cppcheck to try it.

Aside from many other fixes, the Clang code model can now jump to the symbol represented by the auto keyword. It also allows generation of a compilation database from the information that the code model has via Build > Generate Compilation Database.


We added support for simultaneously running debuggers on one or more executables. When multiple debuggers are currently running, you can switch between the instances with a new drop-down menu in the debugger tool bar in Debug mode.

There have been many more improvements and fixes in Qt Creator 4.8, which you can read about in more detail in our change log.

Get Qt Creator 4.8 Beta

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 Beta is also available under Preview > Qt Creator 4.8.0-beta1 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 Beta released appeared first on Qt Blog.

October 10, 2018

At least from the perspective of rendering, text is often the most complex part of a traditional two-dimensional user interface. In such an interface, the two main components are rectangular images and text. The rectangular images are often quite static, and can be represented by two triangles and four indexes into a texture atlas that is uploaded to graphics memory once and then retained. This is something that has low complexity and which the graphics hardware has been optimized to handle quickly.

Text starts as a series of indexes into an international database of writing systems (Unicode). It is then, based on some selection algorithm, combined with one or more fonts, which is in principle a collection of shapes and some lookup tables and executable programs that convert said indexes into shapes and relative positions. These shapes, basically filled paths made out of bezier curves, then have to be rasterized at a specified size, and this can range from simple and neat outlines to complex ones with lots of detail. (By rasterization, I mean finding out how much of each target pixel, or subpixel in some cases, is covered by the shape.)

The letter Q

Objectively the most beautiful character in the Latin alphabet. Here represented by a rasterized image of three channels, respectively giving the coverage of the red, green and blue target subpixels. Scaled by 400% to make the pixels visible.

All combined, it is a heavy process. But luckily, instead of redoing every step for every string, we can often cache intermediate results and reuse them later.

For instance, it is possible to rasterize the glyphs the first time they are used, keep this in memory, and then at each subsequent use, render these glyphs the same way images are rendered as described above: By putting the rasterized glyphs in a texture atlas and representing the glyphs by two triangles and indexes into this atlas. In fact, when the Text.NativeRendering render type is in use in Qt Quick, this is precisely what happens. In this case, we will ask the underlying font system (CoreText on macOS, GDI/DirectWrite on Windows and Freetype on Linux) to rasterize the glyphs at a specific size, and then we will upload these to a texture atlas which can later be referenced by the triangles we put on the screen.

Texture glyph cache

Contents of texture atlas in a typical Qt application.

There are some limitations of this approach however: Since the font size has to be known before the glyphs are rasterized, we may end up rasterizing and caching the same glyphs multiple times if the text in the UI comes in many different sizes. For some UIs that can be too heavy both for frame rate and memory consumption. Animations on the font size, for instance, can cause us to rasterize the shapes again for every frame. This rasterization is also done on the CPU, which means we are not using the resources of the device to its full potential when preparing the glyphs.

Additionally, transformations on the NativeRendering text will give pixelation artifacts, since they will be applied to the pre-rasterized image of the glyph, not its actual mathematical shape.

So what is the alternative?

For a more flexible approach, we want to actually do the rasterization on the GPU, while rendering our frame. If we can somehow get the shapes into the graphics memory and rasterize them quickly using a fragment shader, we free up CPU resources and allow both transformations and size changes without any additional penalty on performance.

There are several approaches to this problem. The way is is done in Qt is by using so-called distance fields. Instead of storing the rasterized glyphs in texture memory, we store a representation of the shapes in a texture atlas where each texel contains the distance to the nearest obstacle rather than the coverage.

Distance field for letter Q in Deja Vu Sans

A distance field of the same Q, as an 8-bit map where each value is set to the distance to the nearest point on the outline of the glyph

Once these distance fields are created and uploaded to texture memory, we can render glyphs at any font size and scale quickly on the GPU. But the process of converting the shapes from the fonts into distance field is still a bottle neck for startup time, and that in particular is what this blog is about.

So what is the problem?

Creating the distance fields is CPU-bound, and – especially on lower-end hardware – it may be very costly. By setting the QT_LOGGING_RULES environment variable to “qt.scenegraph.time.glyph=true” we can gain some insight into what that cost is. Lets for instance say that we run an example that displays 50 unique Latin characters with the Deja Vu Sans font (the simple and neat outlines further up). With the logging turned on, and on an NXP i.MX6 we have for testing in our QA lab, we get the following output:

qt.scenegraph.time.glyph: distancefield: 50 glyphs prepared in 25ms, rendering=19, upload=6

From this output we can read that generating the necessary assets for these 50 glyphs took 19 ms, over one whole frame, whereas uploading the data to the graphics memory took 6 ms. It is the 19 ms for converting into distance fields that we will be able to reduce. These 19 ms may not seem like a lot, but it will cause the rendering to skip a frame at the point where it happens. If the 50 glyphs are displayed at startup, then those 25 ms may not be as noticeable, but if it is done during an animation, it would be something a user could notice. It is worth mentioning again, though, that it is a one-time cost as long as the font remains in use.

Running the same for the HVD Peace font (linked as the complex font above), we get the following output:

qt.scenegraph.time.glyph: distancefield: 50 glyphs prepared in 1016ms, rendering=1010, upload=6

In this case, we can see that rendering the distance fields takes a full second, due to the high complexity of the outlines in use.

Another use case where we may see high costs of generating distance fields is if the number of unique glyphs is very high. So let us test an arbitrary, auto-generated “lorem ipsum” text in Chinese with 592 distinct characters:

qt.scenegraph.time.glyph: distancefield: 592 glyphs prepared in 1167ms, rendering=1107, upload=60

Again, we see that generating the distance fields takes over one second. In this case, the upload also takes a bit longer, since there is more data to be uploaded into graphics memory. There is not much to be done about that though, other than making sure it is done at startup time and not while the user is watching a smooth animation. As mentioned, though, I will focus on the rendering part in this blog.

So what is the solution?

In Qt 5.12, we will release a tool to help you improve on this for your application. It is called “Qt Distance Field Generator” and you can already find the documentation in our documentation snapshot.

The way this works is that it allows you to pregenerate the distance fields for either a selection of the glyphs in a font or all of them. Then you can append these distance fields as a new font table at the end of the font file. Since this custom font table follows SFNT conventions, the font will still be usable as a normal TrueType or OpenType file (SFNT mandates that unsupported font tables are ignored).

So the font can be used as normal and is still compatible with e.g. Qt Widgets and Text.NativeRendering, where the rasterization will still go through the system.

When the font is used in Qt Quick with Text.QtRendering, however, the special font table will be detected, and its contents will be uploaded directly to graphics memory. The cache will therefore be prepopulated with the glyphs you have selected, and the application will only have to create distance fields at runtime if they are missing from this set.

The result of this can be impressive. I repeated the experiments, but with fonts where I had pregenerated distance fields for all the glyphs that were used in the example.

First example, simple and neat “Deja Vu Sans” font, 50 latin characters:

qt.scenegraph.time.glyph: distancefield: 50 pre-generated glyphs loaded in 11ms

Second example, complex “HVD Peace” font, 50 latin characters:

qt.scenegraph.time.glyph: distancefield: 50 pre-generated glyphs loaded in 4ms

Third example, 592 Chinese characters:

qt.scenegraph.time.glyph: distancefield: 592 pre-generated glyphs loaded in 42ms

Comparison of results on i.MX6

As we can see, there is a great improvement when a lot of time is spent on creating the distance fields. In the case of the complex font, we got from 1016 ms to 4 ms. When more data is uploaded, that will still take time, but in the case of the Chinese text, the upload was actually faster than when the distance fields were created on the fly. This is most likely a pure coincidence, however, caused by the order of the glyphs in the cache causing slightly different layouts and sizes.

Another peculiar thing we can see is that the complex font is faster to load than the simple one. This is simply because the glyphs in that font are square and compact, so there is not a lot of unused space in the cache. Therefore the texture atlas is a little bit smaller than for the simpler font. The complexity of the outlines does not affect the loading time of the atlas of course.

Running the same tests on my Windows Desktop workstation, we see that there is not as much overhead for generating the distance fields, but there is still some performance gain to be seen in some cases.

Comparison of results on Windows Desktop

For 50 Latin glyphs with Deja Vu Sans, both tests clocked in at 3 ms, which was mainly spent uploading the data. For HVD Peace, however, generating the distance fields took 131 ms (versus 1 ms for just the upload) and for the Chinese text it took 146 ms (vs 11)

Hopefully this can help some of you get even better performance out of your Qt devices and applications. The feature is already available in the Qt 5.12 beta, so download the package and take it for a test drive right away.

The post Introducing the Distance Field Generator appeared first on Qt Blog.

Older blog entries

Planet KDE is made from the blogs of KDE's contributors. The opinions it contains are those of the contributor. This site is powered by Rawdog and Rawdog RSS. Feed readers can read Planet KDE with RSS, FOAF or OPML.