October 22, 2018

Una vez lanzado Plasma 5.14 ya se empiezan a perfilar las novedades que nos ofrecerá la siguiente versión del escritorio de la Comunidad KDE. Es por ello que me complace compartir con vosotros que Latte Dock será multicolor en Plasma 5.15, una nueva funcionalidad que mejorará su integración visual con el entorno de trabajo.

Latte Dock será multicolor en Plasma 5.15

Como he comentado en el blog, Latte Dock es una creación conjunta del par de desarrolladores de Now Dock y Candil Dock, es decir, psifidotos y @audoban respectivamente. Ambos colaboraron para crear una barra de tareas de aspecto excelente, y funcionalidades y personalizaciones asombrosas y crecientes.

Este resultado fue posible gracias a la inestimable ayuda gráfica de @varlesh, que dotó al proyecto de un diseño propio espectacular que ha cautivado a una legión de usuarios.

El pasado 21 de octubre fue anunciada en el blog de Psifidotos una nueva funcionalidad de Latte Dock que será ofrecida, si no hay problemas, en la próxima versión de Plasma 5.15.

Esta nueva característica será que Latte Dock adoptará el color del escritorio Plasma 5.15 automáticamente ya que básicamente la barra de tareas preguntará a KWin sobre el esquema de color que utiliza y Latte Dock podrá utilizar esa información para adaptarse.

No obstante, si hay un vídeo explicativo esto se ve a la perfección:

Más información: Psifidotos

¿Qué ofrece Latte Dock?

Aunque os aconsejo visitar la página oficial de Latte Dock para ver todas las funcionalidades detalladas, aquí os hago un pequeño resumen:

  • Efecto zoom al pasar el puntero por las aplicaciones.
  • Posibilidad de añadir tantos docks como queramos
  • Soporte de multimonitor.
  • Diversos modo de visibilidad así como la posibilidad de ajustar los tiempos de acciones como el ocultamiento automático.
  • Ajustable  dinámicamente al tamaño de la pantalla.
  • Posibilidad de exportar e importar las configuraciones

Latte Dock será multicolor en Plasma 5.15

En definitiva, Latte Dock se postula como una de las alternativas más espectaculares del entorno Plasma 5 de la Comunidad KDE, un ejemplo más de las infinitas posibilidades de este gran proyecto.

Lo podéis encontrar tanto en la Store de KDE como en Github.

October 21, 2018


Latte Dock  is updating its painting the next months. Let's see what is coming...

In the video you can see the upcoming coloring mechanism of Latte's next version. Even though I am using plasma 5.14 and I love it, it is also the reason I am already expecting impatiently plasma 5.15 this January!! :) This functionality can be supported only with plasma 5.15 .

- youtube presentation -


Latte has updated some of its parts in order to do the following. It is informed from KWin about the color scheme of the active window and uses that information to be painted. The big advantage of the new implementation is that this is done per applet. That means that each applet can decide to be painted by itself and use the Latte color palette. Latte takes responsibility of tracking when the painting should take place and what colors should be used. This is published to applets that support it through just qml code and then applets can paint themselves based on the Latte published palette.

I used the Active Window Control to demonstrate it. Watch in the video how the Active Window Control icon is not colorized and keeps its colourfulness at all times and how the menu items are always painted with fantastic contrast including when they are highlighted... :)

Many kudos to Server Side Decorations and KWin developers that defended them... :)

I have set the top panel maximum length at 95% on purpose because I wanted to present you the plasma theme roundness. The plasma theme shadows can be used with no issues and this is why I activated them when Latte becomes solid. You will be able to use whatever plasma theme suits you best.

A few more details to watch in the video, systemsettings and libreoffice both are using slightly different lightish color schemes. When yakuake is activated the top panel is colorized with the same color scheme. Konsole looks fantastic in its darkish style :) .

With the KDE Frameworks 5.50 release, the KSyntaxHighlighting framework was re-licensed to the MIT license.

This re-licensing only covers the actual code in the library and the bundled themes but not all of the syntax highlighting definition data files.

One of the main motivation points was to get QtCreator to use this, if possible, instead of their own implementation of the Kate highlighting they needed to create in the past due to the incompatible licensing of KatePart at that time (and the impossibility to do a quick split/re-licensing of the parts in question).

We talked about that possibility on Akademy this year and it seems, that if time permits, this will be picked up by the QtCreator team.

The current state allows the use of this tier 1 framework by projects like Qt(Creator), that require non-copyleft licenses for bundled 3rd-party source components, but in addition also for commercial applications that do static linking against a commercial Qt version.

Whereas at the moment, the QtCreator integration has not yet started (at least I am not aware of any work for that), a first commercial consumer already exists.

The company AbsInt I work at does develop both binary and source level analysis tools. Our GUI is Qt based, statically linked with a commercial license.

Before the current release, our GUI used a handcrafted highlighter for our own annotation languages and the programming languages we support (e.g. C and C++). After the release of the 5.50 MIT licensed KSyntaxHighlighting, this was changed to use the framework through its QSyntaxHighlighter implementation.

The framework was easy to integrate into our static build process.  To make it possible to be used without violating licensing for the bundled highlighting definitions that are not MIT and ensure no other installed instances of the framework will mess up the shipped highlighting definitions, the following two changes were contributed upstream.

A CMake switch to disable the bundling of the syntax definition data files into the library. This avoids mixing non-MIT files into the created static library, which then only contains MIT licensed code and data. One can then let people either download the definitions or ship some as extra data files with an extra licensing.

cmake -DQRC_SYNTAX=OFF

A CMake switch to disable the lookup for syntax and theme definitions in the normal locations via QStandardPaths. This allows the user of the library to only load definitions from search paths specified manually. No definitions that e.g. are installed by users for Kate or other applications using the framework will mess up your lookup, which is really important if you rely on exactly your files to be used.

cmake -DNO_STANDARD_PATHS=ON

These two options might be interesting for the QtCreator people, too. If they need additional configurability, I am sure we can find ways to integrate that.

After the transition, my colleagues compared the speed of the old implementation versus the new generic highlighting engine. At first, they were not that impressed, which did lead to several performance improvements to be implemented and up-streamed.

All directly visible bottle-necks got perf’d away. The most CPU consumption now more or less boils down to the costs of the used regular expressions via QRegularExpression. Same for the allocations, we reduced them by taking a look on the heaptrack profiles for the KSyntaxHighlighting benchmark suite.

But as always, performance work is never done, if you have time, you can take a look by profiling the “highlighter_benchmark” autotest, that applies the shipped highlightings to the test files we have in the repository.

There is no divergence in the local git clone at AbsInt at the moment, nor is there any plan to have that in the future. Both sides profit from up-streaming the changes. Other consumers of the framework get improvements and AbsInt doesn’t need to maintain a patched version.

Starting with the 18.10 release of our tools, all highlighting is handled by the framework, no more error-prone handcrafting of QSyntaxHighlighter implementations.

Thanks to all people that helped making this possible ;=)

I hope more projects/companies will pick up the use of this pure qt-dependent tier 1 framework in the future and up-stream their improvements. Be welcome.

Prepare yourself for another avalanche of Usability & Productivity, because here it comes!

New Features

Bugfixes

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.

El nuevo escritorio de la Comunidad KDE ya lleva con nosotros algo más de una semana, en la cual ya ha recibido una actualización, celebrado el 22 aniversario de KDE e inspirado algunos vídeos, como el que hoy nos ocupa de 5 novedades de Plasma 5.14. Una buena forma de enterarte de algunas de las nuevas funcionalidades que te ofrece ahora el más completo escritorio GNU/Linux que puedes tener en tu PC.

5 novedades de Plasma 5.14

Un domingo es un buen momento para disfrutar de un vídeo

De esta forma, y de la mano de linux made simple, nos llega un pequeño vídeo de menos de cuatro minutos donde se repasan las novedades más destacadas de Plasma 5.14.

Para ello ha dividido el vídeo en 5 secciones: plasmoides, monitor del sistema, pantalla de bloqueo, Discover y Wayland. Y ha repasado cada una de ellas con sus principales nuevas características.

Y no olvidéis, si os ha gustado el vídeo darle un like y, si tenéis más tiempo, escribir un comentario. Ese es el combustible de los creadores de contenido.

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
  • Nuevo fondo de pantalla.

5 novedades 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 20, 2018

Esta noticia es vieja, en términos de hoy en día, pero quería dedicarle el tiempo necesario para redactarla e informarme bien. El anuncio se realizó el 15 de octubre y básicamente dice lo siguiente: Handshake Foundation dona 300000 dólares a KDE. Otra gran donación que complementa a la que ya hiciera la Fundación Pineapple hace unos meses y que no puede ser mejor regalo de cumpleaños al Proyecto KDE, que el pasado sábado cumplió 22 años.

Handshake Foundation dona 300000 dólares a KDE

La bomba fue lanzada el lunes 15 de octubre, la Fundación Handshake, responsables de la implementación de un protocolo alternativo a DNS, realizaba una importante donación económica a la Comunidad KDE en forma de 3000000 dólares, convirtiéndose así en la mayor donación recibida por el Proyecto KDE.Handshake Foundation dona 300000 dólares a KDE

Handshake Foundation dona 300000 dólares a KDE

Además, se información que la tercera parte de dicha donación, es decir, 100 mil dólares van a ir destinados íntegramente al desarrollo de la Suite Ofimática de la Comunidad KDE Calligra, un poyecto que necesita mucho amor para convertirse en una verdadera alternativa al gran LibreOffice.

En palabras de Rob Myers de Handshake Foundation:

“Handshake se complace en apoyar a la comunidad internacional de voluntarios dedicados de KDE y su compromiso continuo con el entorno de escritorio gratuito con el lanzamiento actual de KDE Plasma 5 y la suite de oficina de Calligra ”

Evidentemente, se espera que los frutos de esta contribución pronto serán visibles y estarán disponibles para todo el mundo.

Como dije en la primera gran donación, esta es una gran noticia para el software libre en general, ya que estas importantes donaciones, pueden ser un catalizador para que otras fundaciones sigan el ejemplo o para que las instituciones públicas se den cuenta del incalculable valor del trabajo que está realizando la Comunidad KDE en particular y el Software Libre en general.

Más información: KDE News

 

October 19, 2018

In August of last year, i wrote a blog entry about my experience at Akademy 2017 in the amazing Almería, and in that blog entry, amongst many other things, i wrote about an effort which had been slowly brewing, conceptually, for about a year by then: Tagging support in the Open Collaboration Services API. Now, what does that have to do with the KDE Store, you might say? Well, that is the API used by the KNewStuff framework to interface with the store, and that in turn is what is used in the many various places in our software which show shiny, new content for downloading (or to put it in a different way: used by our software to let users Get Hot New Stuff).

For Your Immediate Consumption

I am proud to announce that as of KDE Frameworks 5.51.0, a major patch for KNewStuff was merged, which expands substantially on some basic tag data handling functionality previously added to the Attica framework. One thing it includes, amongst others, is a test tool. Have a screenshot, because those are shiny and make people look at blog entries ;)

A usable test tool for KNewStuff would make testing KNewStuff easier, you say? Well, in that case, have a usable test tool for KNewStuff.

Some of you brave people running Frameworks from Neon's nightly packages saw an explosion when using Discover a few weeks ago, and i'd just like to also extend an apology to you, as that was my fault for temporarily introducing a binary incompatibility in the first merged version of that patch. Thank you, also, for actually running this, as without you we might have not found this bug before releasing, at which point it would have been too late to fix. So, thank you for your invaluable testing and reporting work! This double merge of the patch is also why you might notice two entries of that patch being mentioned in the changelog.

Immediate Culminations

So, apart from shiny new test tools, what sort of shiny things can you, as a user or developer of KDE software, expect when running it on top of KF5.51? Well, one important thing you will notice (or, rather, hopefully not notice too much) is that the content offered to you in for example Plasma's Get New Wallpapers dialogue or KDEnlive's templates are going to be both installable and usable. This does require intervention by the KDE Store's moderators, who are the ones that can mark content as something KNewStuff should hide by default, and is why a call went out for assistance there a couple of months ago, so we could prepare for the arrival of this patch. Incidentally, if you find anything off on the store, please do tell us about it and we'll get right on it!

One very important point i feel i need to make before continuing: The basic filtering functionality I'm about to describe is entirely backward compatible, with no side effects other than the filtering just not happening if an application using it is run on top of an older version of KNewStuff. This means if you want to add this to your software, you won't need to wait for your favourite distros to get all up to date with Frameworks.

As an example of something slightly more involved than just hiding those bits explicitly marked as unwanted on the server, have a couple of screenshots of a bit more of the functionality in this patch. On the left we have the test category Comics on share.krita.org, with one comic (supplied as an ePub file in this case), one non-downloadable comic (still technically a comic, but it's a link to a website - technically fine for this category, but not downloadable), and one spam entry (fairly sure this stuff isn't a comic book of any kind...). On the right, the same data is shown in Peruse,  but with the two non-usable entries filtered out for having either no comic to download, or for being spam and explicitly excluded by a moderator.

No modifications were done in Peruse's code itself either, only the knsrc configuration file, which had the following line added to it:

DownloadTagFilter=data##mimetype==application/x-cbz,data##mimetype==application/x-cbr,data##mimetype==application/x-cb7,data##mimetype==application/x-cbt,data##mimetype==application/x-cba,data##mimetype==application/vnd.comicbook+zip,data##mimetype==application/vnd.comicbook+rar,data##mimetype==application/vnd.ms-htmlhelp,data##mimetype==image/vnd.djvu,data##mimetype==image/x-djvu,data##mimetype==application/epub+zip,data##mimetype==application/pdf

This somewhat unsightly chunk means, fairly simply, that there should be a filter on the content item's download items, which should accept only entries in which at least one of those download items had one of the listed entries for the data##mimetype tag. The documentation for the filtering of content items can be found right over here and here for download item tags, alongside KNewStuff's other API documentation.

If you want to do something more involved than what is possible using a static list of tags like that, you can absolutely add the filters manually through code. Do this by calling the KNSCore::Engine::addTagFilter and addDownloadTagFilter functions, using the formats listed in TagsFilterChecker's documentation.

Future Prospects

What does the future hold? Well, for KNewStuff itself, the functionality as it stands now is pretty powerful already, but if you have ideas for enhancements, please do get in touch, either directly to me (i'm not difficult to find, to the best of my knowledge i'm the only leinir around), or on IRC (i'm leinir on many of KDE's various channels on Freenode and on our Telegram groups, on Twitter and so on), or even better, surprise us with a patch over on Phabricator.

What are all these AppImage being filtered by architecture? Well, then, that's certainly something we should perhaps be doing more of now that it's possible to do so... ;)

One future prospect which is very immediate is going to be enhancing the KDE Store support in Discover. Right now, Discover's support for content coming through KNewStuff is limited to, effectively, just showing the items offered by all the knsrc files on the system and managing their installation and removal. This is already lovely, but enhancing this functionality by adding such things as explicit, user specified filtering or browsing through tags supplied by the creators, or by computer architecture and the like for things which require running would be very handy (for example for supporting downloading and installing AppImages from the AppImage section on the store).

Thank You!

The future, then, is very much full of shiny possibilities, and while i am under no illusion that anybody is going to be quite as enthusiastic as someone who has been working (on and off) on this functionality for over two years, i do hope that some of my excitement might have rubbed off on you.


The word (/abbreviation) of the day is: SABA (because having supplied air breathing apparatus would be handy with the bitumen removal chemicals being used in our house at the moment)

A new release of Kraft, the Qt- and KDE based software to help to organize business docs in small companies, has arrived.

A couple of days ago version 0.82 was released. It mainly is a bugfix release, but it also comes with a few new features. Users were asking for some new functions that they needed to switch to Kraft with their business communication, and I am always trying to make that a priority.

The most visible feature is a light rework of the calculation dialog that allows users to do price calculations for templates. It was cleared up, superflous elements were finally removed and the remaining ones now work as expected. The distinction between manual price and calculated price should be even more clear now. Time calculations can now not only done in the granularity of minutes, as this was to coarse for certain usecases. The unit for a time slice can now be either seconds, minutes or hours.

Kraft 0.82

New calculation dialog in 0.82

Apart from that, for example sending documents per email was fixed, and in addition to doing it through thunderbird, Kraft can now also utilize the xdg-email tool to work with the desktop standard mail client, such as KMail.

Quite a few more bugfixes make this a nice release. Check the full Changelog! Update is recommended.

Thanks for your comments or suggestions about Kraft!

Do you remember QML Book? It started as a project between me and Jürgen Bocklage-Ryannel where we tried to fix the problem that there is no QML book out there.

Back in the Qt 5.2 days, we spent wrote about a year. Unfortunately, the project has mainly been sitting idle since then. I’ve poked at issues every now and then, and Jürgen has done various fixes as well.

Thanks to The Qt Company, this is changing. This autumn, it sponsors me to work on the project. The current plan is to add a chapter to Qt Quick Controls 2, and to update the entire contents to Qt 5.12 and Qt Creator 4.8. By doing so, many of the remaining bug reports will be resolved.

Other things in the backlog are getting the CI system back into shape and having a native speaker edit the language. All in all, this will result in an up-to-date book on QML. If you want to help out, just reach out to me or send me your pull requests. All help is welcome!

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:

https://wiki.ubuntu.com/CosmicCuttlefish/ReleaseNotes/Kubuntu

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).

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.

Example

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

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

    int rowCount(const QModelIndex &parent) const override {
        Q_ASSERT(checkIndex(parent));
        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);
        m_strings.append(string);
        endInsertRows();
    }

private:
    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, 
                          QAbstractItemModelTester::FailureReportingMode::Warning);

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
   (qabstractitemmodeltester.cpp:669)

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).

Remarks

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

@tetris4 wrote:

Also available in Italian, Spanish and Taiwanese Mandarin.

Hi everyone!

This time we have been a bit late, as many of our contributors were busy over the last couple of months, but we hope we can soon get back to normal delivery times. :blush:

Better late than never though, so we are happy to inform you that on your next system upgrade you will receive newer versions of KDE’s Plasma, Applications and Frameworks, in addition to updates to important packages such as the linux kernel and systemd. The latest Plasma 5.14 series should follow soon.

Please have in mind that we have removed the nvidia-304xx package from Chakra’s repositories because it is no longer compatible with new kernel releases. If you are using nvidia-304xx on your system, you should either install and use the linux-lts kernel and the corresponding nvidia-304xx-lts package, or switch to the free nouveau driver.

For more details and the full changelogs on KDE’s software releases, you can read the official announcements:

13-wee

Noteworthy package updates include:

[core]

  • curl 7.61.1
  • gcc 8.2.0
  • linux 4.18.12
  • linux-lts 4.4.152
  • nvidia 410.57
  • nvidia-390xx 390.87
  • openssh 7.8p1
  • systemd 239.0
  • vlc 3.0.4

[lib32]

  • wine 3.18

It should be safe to answer yes to any replacement question by the package manager application. If in doubt or if you face another issue in relation to this update, please ask or report it below.

Most of our mirrors take 12-24 hours to synchronize with the central repositories on the origin server. Use the mirror status web page to see when your mirror of choice last synchronized.

Enjoy!

Posts: 15

Participants: 10

Read full topic

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!

October 16, 2018

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.

Handshake

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?

www.aflasio.com

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.

Thanks,

... 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

Bugfixes

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.


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.