December 14, 2018

In Qt for Device Creation 5.12.0, we have enabled additional content installation via QBSPs (Qt Board Support Packages). A QBSP combines toolchain, target device images and set of Qt Creator configurations for particular device into a single file that can be easily shared and installed using the Qt online installer or the Maintenance tool. Technically a QBSP is an archived repository created by the Qt Installer Framework, and it’s creation is now fully integrated into the Yocto builds that are used to create the Boot to Qt Software Stack content.

For all the target devices currently supported in the meta-boot2qt layer, you can create a QBSP simply by issuing a bitbake command:

bitbake meta-b2qt-embedded-qbsp

This will first build both the toolchain and the image, and then package those into a QBSP file with the required Qt Creator configurations. The resulting QBSP file is located in tmp/deploy/qbsp/ folder in your Yocto build environment. The QBSP packaging respects the SDKMACHINE variable, so that if you use environment variable SDKMACHINE=i686-mingw32, a Windows toolchain is packaged into the QBSP.

The Yocto integration is implemented in two classes that can be used even if your target device has not been otherwise integrated into the meta-boot2qt layer. By inheriting the classes and setting up the required variables, you can have a QBSP with your own image for your own target device.


The QBSP will need a suitable device image to include in the package and to achieve this you will need to inherit qbsp-image.bbclass in the image recipe you want to use. You can control the content of the package with variable QBSP_IMAGE_CONTENT. By default Boot to Qt images include a .img file and a .conf file used by the Flashing Wizard.

inherit qbsp-image

  ${IMAGE_LINK_NAME}.img \
  ${IMAGE_LINK_NAME}.conf \


qbsp.bbclass is the main class that handles the creation of the QBSP and you can control the various aspects of it through variables. Most important ones are the dependencies to the toolchain and image task using QBSP_SDK_TASK and QBSP_IMAGE_TASK variables.

For the Boot to Qt Software Stack, this is done in the recipe:

inherit qbsp

VERSION_SHORT = "${@d.getVar('PV').replace('.','')}"
QBSP_NAME = "Boot2Qt ${PV}"
QBSP_MACHINE = "${@d.getVar('MACHINE').replace('-','')}"

QBSP_SDK_TASK = "meta-toolchain-b2qt-embedded-qt5-sdk"
QBSP_IMAGE_TASK = "b2qt-embedded-qt5-image"

Rest of the variables are then used to control how the installer shows the component and where they are installed. You can optionally also, e.g., add an EULA to the package, which the user would need to accept before they can install the components. You can find this and all the other information about the QBSP specific variables in the documentation <link to device creation / QBSP docs>.

The post How to create QBSPs from Yocto builds appeared first on Qt Blog.

December 13, 2018

This week I gave KDE Frameworks a web page after only 4 years of us trying to promote it as the best thing ever since cabogganing without one.  I also updated the theme on the KDE Applications 18.12 announcement to this millennium and even made the images in it have a fancy popup effect using the latest in JQuery Bootstrap CSS.  But my proudest contribution is making the screenshot for the new release of Konsole showing how it can now display all the cat emojis plus one for a poodle.

So far no comments asking why I named my computer thus.

Facebooktwittergoogle_pluslinkedinby feather

It's that time of the year again. Everyone is in a festive mood and excited about all the new things they're going to get. It's only natural, since it's the season of the last KDE Applications release for this year!

With more than 140 issues resolved and dozens of feature improvements, KDE Applications 18.12 are now on its way to your operating system of choice. We've highlighted some changes you can look forward to.

Practical File Management with Dolphin

File management encompasses a lot of activities. There's renaming, copying, and moving files around. Perhaps you want to quickly preview a file to make sure it's the right one. You're in luck, because the thumbnail preview experience has been greatly improved in the new version of Dolphin. LibreOffice documents and AppImage applications can now be previewed as thumbnails, and icon thumbnails look much cleaner. If folder thumbnails are enabled, video files larger than 5 MB will be visible in them.

Of course, there is more to Dolphin than just thumbnails. The "Control" menu makes it easier to show hidden places and create new files and folders. After unmounting a storage volume in the Places panel, it can now be remounted. Those who still own audio CDs and use Dolphin to open them will be glad to hear it can now change the CBR bitrate for MP3 files and fix timestamps for FLAC files.

Some security measures have been implemented in Dolphin to prevent users from accidentally losing their data. It no longer allows attempts to unmount the active home directory and the disk where the active OS is installed. When renaming files, Dolphin will warn you if there's an extra dot in front of the filename, which would make the file hidden. Pretty neat, right?

Okular: Annotate ALL the Things

Okular with the new Typewriter tool

Okular has steadily grown from a document viewer into an indispensable assistant in activities such as studying, doing research, or collaborating on text in read-only file formats like PDF and EPUB. Its annotation capabilities were already powerful, but the new version introduces a new tool called Typewriter. With this annotation tool, you'll be able to write text literally anywhere in your files. Whether it's commenting on an image or highlighting a spelling mistake, your hands are now untied, and you can freely express yourself in Okular.

Other improvements in this release include better options to expand and collapse entries in the Table of Contents sidebar. If a file contains links, hovering over them will always display the full URL in a tooltip, regardless of the currently selected Okular mode.

Konsole, Now with More Emotion

Spending hours or even days working in the terminal can get monotonous. Cheer up - the new version of Konsole has full support for emoji! Add a cheeky smiling cat to your commit messages, or insert a facepalm emoji into your shell scripts.

If you're into more serious things, Konsole now makes it easier to reset the font size back to the default. When a bell is triggered in an inactive tab, the tab icon will be highlighted to visually alert you of the activity. Last but not least, if your mouse has back and forward buttons, Konsole is now able to recognize them, and you can use them to switch between tabs.

Usability Improvements for Everyone

If you have been keeping up with KDE-related news, you're probably aware of our community-wide Usability Improvement goal. After all, it's hard to miss the weekly updates from our awesome developers who are dedicated to making the KDE software more accessible and friendlier to everyone.

The KDE Applications 18.12 release integrates all those fruits of labor, and the result is a much more pleasant user experience across the board. KMail now supports a unified inbox display, and emails should now be readable regardless of your color scheme. A small improvement with a big impact is the ability to repeat the last calculation in KCalc multiple times.

Kate comes with new defaults that are meant to help you work more productively right from the start. Specifically, line numbers and the Text Filter plugin will be enabled by default. You can now change the focus of the embedded terminal in Kate by pressing the F4 key, and it will automatically synchronize the location in the terminal with the location of the currently active document.

in 18.12 Kate comes with better defaults

If you are using Gwenview to fix the wretched red-eye effect in your photos, it will now be even easier thanks to the improved Reduce Red Eye tool. When taking screenshots with Spectacle, their filenames will be sequentially numbered by default. You will also notice that saving options in Spectacle are now easier to access from the Save page.

New Spectacle makes it easier to save screenshots

Ark has received support for tar.zst archives, and it's now much smarter when it comes to file previews. Instead of previewing document files as archives, Ark will now launch the appropriate application for the selected file format.

Apart from improving the standard set of applications, we have also made some of our specialized tools more usable. Lokalize, the translation and localization tool, now has a better search functionality that can recognize plural forms of words. If you keep a lot of tabs open in Lokalize, you will be able to navigate between them much faster.

Cantor, the advanced mathematical tool, now offers better visualizations and highlighting of command entries. You can also open multiple files in one Cantor shell. For users who need to draw mathematical functions, we have made Kmplot more stable and improved the SVG export functionality.

As always, check out the full list of changes in KDE Applications 18.12 to find out more.

Our work on KDE Applications continues, and we can't wait to show you what we've created in 2019. Until then, enjoy the Applications 18.12., and let us know which changes made you the happiest!

Today we’re releasing Krita 4.1.7, another bug fix release in the Krita 4.1 series.

The most important fix is a weird one: it might help your wifi connection. The problem is that we started building a widget that would show you the news feed from The widget isn’t active, and doesn’t make any kind of network connection… But Qt’s network manager class still checks your wifi settings all the time. See these bugs: and

Apart from that, we’ve worked around a bug in Qt 5.12 that would cause an instant crash when using a tablet. Our own builds do not use that version of Qt, so the Windows builds, macOS build and the Linux appimage are fine, but users of rolling Linux releases like Arch would suffer from this issue.

And there are more bug fixes, of course:

  • Fix showing wrongly that there is no audio support in the animation timeline audio menu
  • Disable the disk-based animation cache rendering backend on Windows: this would give problems with animations bigger than about 150 frames. (BUG 401326)
  • Don’t hang when trying to load recent files thumbnails for files in a location that’s no longer accessible. (BUG:401939)
  • Make it possible to use the LUT docker when Angle is enabled on Windows. We have also updated the OpenColorIO library to the latest release.
  • Remember whether anti-aliasing was enabled in selection tools (BUG:401730)
  • Add a shortcut to activate the text tool (BUG:401655)
  • Make the toolbars movable again
  • Make Select by Color Range check the entire image (BUG:346138)
  • Enable HiDPI support by default: the problems with the canvas scaling have been solved.
  • Allow krita to import more than file at a time when started from a file manager (BUG:401476)
  • Fix using the scrollwheel in comboboxes on Linux (BUG:399379) Patch by Mykola Krachkovsky.
  • Fix the calculation of Average Desaturation (BUG:400493)
  • Do not crash when exporting Compositions (BUG:400627)
  • Make the move tool show the correct cursor in all modes
  • Let the move tool move invisible layers
  • Fix a crash in the artistic color selector (BUG:399860)



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

Es un buen momento para volver a publicar este recordatorio. KDE España busca sede para Akademy-es 2019,  lo que será su decimocuarta edición de Akademy-es, un encuentro entre desarrolladores, usuarios, diseñadores, traductores, simpatizantes o cualquier otro grupo de personas que le interese este proyecto de Software Libre que tantas alegrías nos da y nos seguirá dando.

¿Qué es una Akademy-es?

Una Akademy-es es un excelente lugar donde recargar las pilas si estás dentro de KDE a la vez que una excelente forma de empezar a involucrarte. Además os puedo asegurar que son unas jornadas donde se aprenden muchas cosas, siempre te llevas a casa nuevas experiencias, diferentes puntos de vista y …. una camiseta molona.

Recordatorio: KDE España busca sede para Akademy-es 2019

Foto de grupo de Akademy-es 2018 de Valencia

Recordatorio: KDE España busca sede para Akademy-es 2019

El comunicado es breve y escueto, como siempre:
Como cada año, KDE España organiza Akademy-es, el evento relacionado con KDE más importante del año en España, en el que usuarios y desarrolladores se dan cita para compartir experiencias y conocer las principales novedades de KDE a través de diversas actividades, entre las que destacan conferencias y talleres.

Para la celebración de Akademy-es, KDE España solicita la colaboración de un grupo/asociación en calidad de co-organizador, que facilite algunas de las tareas necesarias para hacer de la edición 2019 un éxito de participación y organización.

Las condiciones básicas y los datos necesarios para presentar la candidatura son los siguientes:

  • Datos de contacto
  • Localización. Debe tener capacidad para unas 75 personas con internet y posibilidad de libre acceso.
  • Datos del grupo organizador e instituciones/entidades colaboradoras.
  • Descripción del equipo organizador.
  • Propuestas de hospedaje asequible para todo aquel interesado en acudir desde otras ciudades.
  • Datos relacionados con el acceso a la localización desde otras ciudades (por avión, tren, etc.) así como al lugar de celebración del evento.
  • Descripción de posibles fuentes de financiación. Aunque es preferible poder asegurarla a priori, no se descartarán las propuestas que no cumplan esta condición.
  • Posibles fechas de celebración de Akademy-es. La fecha habitual es durante los meses de abril o mayo, aunque no se descartarán otras propuestas. El evento debe celebrarse preferentemente de viernes tarde a domingo a mediodía.

Foto de grupo de Akademy-es 2016 de Madrid

La fecha límite de presentación de propuestas para la celebración de Akademy-es es el 13 de enero de 2019.

Ante cualquier duda, ponerse en contacto con KDE España (


¡Nos vemos en la próxima Akademy-es!

December 12, 2018

OFX is the Open Financial eXchange protocol used by various financial institutions in a few countries. KMyMoney provides an OFX client implementation using the open source LibOFX library allowing users to import transactions directly from the bank’s server without using the detour through a web-browser and a downloaded file into the ledger of the application.

A while ago, a KMyMoney user reported a problem with a single institution using OFX transaction download. Out of a sudden, this feature did not work anymore and the bank did not allow to login anymore and provided the following error message:

We're very sorry, but that content you are looking for can't be found. Please try the homepage again. If you continue to receive this message, please call the Customer Service number on the back of your card. We apologize for any inconvenience and appreciate your patience.

Since there was no change on the KMyMoney side nor on LibOFX, the problem must have been with the institution. So he contacted their customer support but the answers did not help to solve the problem.

Not surprisingly I got nowhere talking to tech support at the bank. I don’t think anyone answering the phones knows anything about direct connect .”Can you logon to our website” and “reinstall your personal finance software” is about all they could suggest.

A frustrated KMyMoney user about his banks customer support

We know these answers just to well and one can find them on mailing lists and forums of almost any open source finance applications in or another form.

Living in a country where banks don’t use OFX at all, it is kind of hard to support these stranded users. We tried to log the requests and analyze them, but all just looked well according to the OFX specs.

Searching the web, I came across a posting where a GnuCash user reported, that adding a trailing blank to the username and changing the application version in the request solved the problem. This just sounded too strange, so I forwarded this information to the user and he answered:

Not surprisingly… ipwizard does it again!

I changed the APP_VER to 2400 using the KMM online settings as suggested. Then I saved my KMM file in XML, opened the XML and added a space to me user name.

Worked like a charm.

A happy KMyMoney user

I was also able to get it working with KMM 4.8.0. I just unmapped and remapped the account adding a space to the end of the user ID and using 2700 as the version. No XML hacking required.

Another KMyMoney user also being happy

As a side effect of my search, I stumbled across a posting about OFX security issues. Very interesting article which does not surprise me and shows the partial ignorance of banks regarding security on top of their sometimes non-existant customer support if it comes to home banking.

En mi opinión, uno de los puntos débiles del Software libre es la falta de contenido extra para muchas aplicaciones creativas. En otras palabras, creo que son necesarias plantillas de todo tipo y de calidad para programas estilo Impress. Es por ello que me congratula compartir con vosotros 5 plantillas para títulos para Kdenlive con los que podemos mejorar nuestros vídeos.

5 plantillas para títulos para Kdenlive

La Store de KDE es una mina para ir encontrando material accesible para nuestro escritorio o para nuestros documentos. Tenemos desde temas para Plasma, iconos y cursores hasta plantillas para scripts para Mycroft, addons para juegos KDE o, como nos ocupa en esta entrada , material extra para Kdenlive.

Las aplicaciones creativas del Software libre están a la altura de cualquier alternativa privativa pero, como he dicho en la entrada, creo que tenemos un déficit en cuanto a plantillas de calidad o material auxiliar con la que apoyarme para realizar creaciones espectaculares.

Afortunadamente, en la KDE Store nos ofrece en la sección de Kdenlive Title Templates una creciente colección de plantillas para poder decorar y mejorar nuestras creaciones.

5 plantillas para títulos para Kdenlive

De momento ya tenemos 5 plantillas para títulos para Kdenlive que van desde entradillas para presentar una noticia, un banner para los textos que aparecen bajo los noticieros o un rectángulo lateral que nos sirven para presentar características.

El listado completo es el siguiente:

  1. Lower Third Title / Titre pour tier inferieur – Rectangles 1
  2. News ticker title 1.2
  3. Right Blue title 1.2
  4. World title 1.2
  5. Kdenlive testing title 1

Lo mejor de todo es que todo el mundo puede colaborar en este tipo de plantillas ya que no requieren dotes de programación pero si de creatividad.

¿Qué es Kdenlive?

Kdenlive (acrónimo del inglés: KDE Non-Linear Video Editor) (ˌkeɪdɛnˈlaɪv) es un editor de video no lineal para KDE que soporta todos los formatos de vídeos de codificador FFmpeg (DV, HDV, mpeg, avi, mp4, mov, flv, ogg, wav, mp3, vorbis, …) y los formatos de imágenes  clásicas (gif, png, jpeg, xcf, exr, tiff, svg, …)

Además, tiene las siguientes características:

  • Dispone de linea de tiempo con función búsqueda.
  • Copiado y pegado de clips.
  • Función deshacer completa.
  • Captura de por Firewire: DV y HDV
  • Captura por Video4Linux
  • Exporta en diferentes formatos:  mpeg, avi, dv, flash, mov, …
  • Múltiples efectos como: Automask,  Box Blur, Charcoal, etc.

Más información: Kdenlive

Calamares, the Linux system installer for boutique distro’s, is translated into 50 or so languages. It’s not a KDE project, but uses a bunch of KDE technology like the KDE Frameworks and KPMCore. It doesn’t use the KDE translation infrastructure, either, but Transifex.

There’s two languages for Calamares that don’t have any translators — they were requested, and then added to the system, but there is noone to do the work. Those are Macedonian and Uzbek. That said, there are also translations to Lao, Farsi, Gujrati, Urdu and Swiss French (is that even a thing) that have not seen any actual translation work done.

If you’re interested in any of those languages, the Calamares translators guide can get you started.

PS.: boutique distro for me means anything outside the “big five”, it doesn’t say anything about the size or importance of the distro itself.

December 11, 2018

Este año no estoy dejando de lado los eventos que organiza los chicos de Barcelona Free Software. No se me pasó promocionar su charla de Noviembre (si la de Octubre, maldita sea) y hoy promociono la de Diciembre. El próximo 17 tendremos una más que interesante charla en la que conoceremos The Things Network en los meetups de BFS. Si pudiera, no me lo perdería.

The Things Network en los meetups de BFS

The Things Network es un proyecto global que tienen como objetivo construir una red de común  para la IoT (Internet of Things), basada en los principios de apertura, libertad y neutralidad.

The Things Network en los meetups de BFS

Con esta idea se pretende que los los cientos de comunidades que en todo el mundo implementen esta infraestructura ayuden a las personas y entidades a hacer un buen uso de la red.

Para la charla se contará con Xose Pérez,  miembro central de la comunidad de The Things Network en Barcelona y que actualmente trabaja como ingeniero de software freelance. Ha creado y mantiene varios proyectos de código abierto de hardware y software relacionados con la soberanía tecnológica.

Los datos importantes de The Things Network en los meetups de Barcelona Free Software son los siguientes:

Este meetup está organizado por KDE España, la asociación nacional de usuarios y desarrolladores de KDE, un proyecto de software libre que crea el Plasma Desktop y cientos de aplicaciones usando Qt y QML

No te lo pienses. ¡Te esperamos el lunes 17 de diciembre!


Más información: Barcelona Free Software

¿Qué es Meetup?

Las charlas de Barcelona Free Software se organizan mediante Meetup, una red social que tiene una diferencia básica respecto a otras redes sociales, ya que  promueve la formación de grupos en torno a intereses con el fin de que sus miembros se conozcan cara a cara.

Es decir, los usuarios establecen contacto a través de grupos digitales nuevos o ya creados, partiendo de intereses comunes como política, libros, juegos, películas, salud, mascotas,


LetsEncrypt is wonderful — SSL certificates automatically generated and updated. CertBot does the actual work in one of its many incarnations. Most of my sites use LetsEncrypt to auto-renew certificates. Recently the CertBot at my hoster stopped updating, and now certificates are expiring. The hoster isn’t responding to mail asking them to give CertBot a kick in the pants, so I’m starting to look at other options. It’s weird because for the past 10 years they’ve been good Open-Source-Friendly hosters.

If things move there will probably be a hiccup in access, but I’ll give a shout when it does. The Calamares site runs on GitHub, so is unaffected by this whole thing.

In one of the previous blogs we introduced the new capability of LabPlot to calculate and to draw histograms. Given a data set, the user can calculate the histogram using different binning methods and to visualize the calculated histogram in the new plot type “histogram”. A different workflow is given when the histogram was already calculated in another application and the application like LabPlot is just used to visualize the result of such a calculation and to adjust the final appearance of the plot.

Couple of weeks ago Christoph Roick contributed a new input filter for ROOT histograms. ROOT is a computational environment developed at CERN that is used for data processing, statistical analysis and data visualization, mainly for purposes in the high energy physics community. With the new import filter it is possible now to import ROOT histogram files (custom binary format, compressed) into LabPlot:

Import Dialog

In the import dialog the user can specify which data to import. After the import, the data from “bin center” or from “low edge” can be used together with the bin values from the “content” for x- and y-values, respectively, to plot the data. The result of such a workflow is shown in the screenshot below by means of a very simple example:

ROOT Histogram

In this example taken from ROOT Guide for Beginners, 1000 values for the exponential function are created in ROOT and the histogram is calculated and written to a file. The import of data and the visualization are done in LabPlot as described above. Here, the imported x-y pairs are connected by the “step line” in order to get the common shape of the histogram. Other visualizations with symbols only, etc. are possible, of course, too. The plot on the left hand side was created by the built-in plotter of ROOT and is shown here for comparison purposes.

With this new feature we can utilize the power and speed of ROOT and its ability to work with very big amount of data and to use the flexibility of LabPlot to style the visualization of the calculated data. The code has reached master already and we are going to ship this new feature in the upcoming release 2.6 LabPlot.

In parallel, the work to support also the more general data container “tree” in ROOT is already in progress and we hope to finalize it soon. This would further extend the application area of LabPlot in near future.

This is a reminder — for those who don’t read all of the FreeBSD mailing lists — that KDE4 is marked deprecated in the official ports tree for FreeBSD, and will be removed at the end of this year (in about 20 days). Then Qt4 will be removed from the official ports tree in mid-march.

Since both pieces of software are end-of-life and unmaintained upstream already for several years, the kde@ team at FreeBSD no longer can maintain them. Recent time-sinks were dealing with OpenSSL 1.1.1, libressl, C++17, .. the code is old, and there’s newer, nicer, better-maintained code available generally by replacing 4 with 5.

Users are encouraged to migrate to Qt5 and KDE Plasma plus KDE Applications. The easiest way to do so is to follow the instructions on the KDE-FreeBSD community wiki.

December 10, 2018

Last time I tried printing with the raspberry pi I had only one machine to try with now I have two. Lets see if the Pi can handle two instances of AtCore and control two 3d printers at the same time. This is a follow up to AtCore takes to the pi. So please read that for more about the RPi setup. This post is in video form, please enjoy.

December 09, 2018

This week I was briefly in Berlin for the Qt World Summit, or QtWS for short. I was there to run the KDE booth as part of the exposition at the summit, rather than to do any talks (or, for that matter, watch any). First, a bunch of thanks are in order: to Sari and Milja from Moodboard for organising most of the things, to Katica from the Qt Company for doing PR on the show floor, to Kai and Roman from KDE for standing at the booth with me, and to the 700-or-so attendees for listening to us when we talk about KDE as a community, about KDE Frameworks and Plasma in laptops, tablets, phones and embedded. Thanks also to Paul and kde-promo for getting us some nice source material for stickers and shirts.

Photo of Kai and some laptops

Kai at the KDE booth at QtWS

The picture shows some of the stuff we did for the booth: a canvas banner, demo machines, and happy T-shirts. If the Italians (from a Sardinian argricultural-technology firm?) who wanted a T-shirt get in touch with me, we’ll make it happen.

One of the nice things about QtWS is meeting all the KDE people who have wandered away from the active KDE community, and are now inside the Qt Company, or KDAB, or all over the Qt ecosystem. KDAB, of course, gave a bunch of talks at the event and also contributes lots of code to both Qt and KDE; it’s still good to actually meet old KDevelop people and such. When talking to “old hands” is the fordness with which they talk about the community and participating in such a large Open Source project.

So the things we mostly talked about were KDE Frameworks — a fair subset of them are useful for small-footprint devices, embedded, automotive — and that Qt is Open Source. Reminder: Qt is Open Source. And so are all the things KDE builds on top of Qt. There’s a large number of very proprietary software companies around Qt in the automotive world. One really cool one does handwriting recognition, and does it well; I tested it in English, French, and Arabic with my untidy scrawl and its accuracy was pretty good. But .. no, not my cup of tea. The Pinebook got a fair amount of attention, but even more attractive to attendees was a prototype laptop that had been 3D-printed the day before. It looked like it had stepped right out of the 80s, but was running a pretty snappy Plasma desktop on top of mainline and Debian (can’t say more than that for now). We installed KDE neon on my Slimbook again, alongside openSUSE, to try out Wayland, and in particular gaming with Steam under Wayland. That .. turns out to work just fine, but people look at you funny when you’re playing CS:GO (please note my ambivalent and inconsistent treatment of proprietary software here) at the stand.

So, here’s to the Qt community and see you next time!

Continuing on this release month idea started last week, here is a release of another project. Today is the first release of qpropgen, a tool to generate QML-friendly QObject-based C++ classes from class definition files.

I started this project because I did not want to manually define the dozen of properties required to represent a sound in SFXR-Qt, which itself got started because I wanted a sound effect generator for Pixel Wheels. Yes, that's a bit of Yak shaving :)

It works this way: first you define your class and its properties in a yaml file:

class: Person
    - name: firstName
      type: QString
    - name: lastName
      type: QString
    - name: birthDate
      type: QDateTime

Then you run qpropgen person.yaml. It produces two files: person.h and person.cpp.

This is person.h:

// This file has been generated with qpropgen, any changes made to it will be lost!

#ifndef PERSON_H
#define PERSON_H

#include <QObject>

class Person : public QObject {

    Q_PROPERTY(QString firstName READ firstName
            WRITE setFirstName
            NOTIFY firstNameChanged

    Q_PROPERTY(QString lastName READ lastName
            WRITE setLastName
            NOTIFY lastNameChanged

    Q_PROPERTY(QDateTime birthDate READ birthDate
            WRITE setBirthDate
            NOTIFY birthDateChanged

    explicit Person(QObject* parent = nullptr);

     QString firstName() const;
     void setFirstName(const QString& value);

     QString lastName() const;
     void setLastName(const QString& value);

     QDateTime birthDate() const;
     void setBirthDate(const QDateTime& value);


    void firstNameChanged(const QString& firstName);

    void lastNameChanged(const QString& lastName);

    void birthDateChanged(const QDateTime& birthDate);

    QString mFirstName;
    QString mLastName;
    QDateTime mBirthDate;

#endif // PERSON_H

And this is person.cpp:

// This file has been generated with qpropgen, any changes made to it will be lost!
#include <person.h>

Person::Person(QObject* parent)
    : QObject(parent) {

QString Person::firstName() const {
    return mFirstName;
void Person::setFirstName(const QString& value) {

    if (mFirstName == value) {

    mFirstName = value;

QString Person::lastName() const {
    return mLastName;
void Person::setLastName(const QString& value) {

    if (mLastName == value) {

    mLastName = value;

QDateTime Person::birthDate() const {
    return mBirthDate;
void Person::setBirthDate(const QDateTime& value) {

    if (mBirthDate == value) {

    mBirthDate = value;

qpropgen comes with a CMake file to include in your project. Contributions adding support for other build systems are greatly appreciated :)

There is more to it: you can define read-only properties, make setters and getters virtual and a few other tweaks. You can learn more about qpropgen from the README.

Let me know if you find this tool useful!

This week in Usability & Productivity, our flagship Kate text editor got a lot of love–and there’s more in the pipeline too! But that’s not all…

New Features

Bugfixes & Performance Improvements

User Interface Improvements

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

December 08, 2018

One obvious aspect of KDE’s privacy goal is eliminating all network connections that are not using transport encryption. That’s however not as straightforward to ensure as it may sound, it’s easy to have a long forgotten HTTP link in a rarely used dialog that should have been changed to HTTPS many years ago already. How do we find all these cases?


First of all, this is not about intentional or malicious attempts to bypass or weaken transport encryption at any level, but about finding our own mistakes. That is, simple typos forgetting the crucial ‘s’ after ‘http’, or legacy code from a time before the corresponding service even supported transport encryption.

This is also not about identifying servers that only offer weak or otherwise broken transport security, and communicating that to the user as we are used to from web browsers. All of that needs to be looked at too of course, but that’s a different task.

Source Code

Naively, searching the source code for http: and replacing it with https: would be a good start. However, it’s a bit more complicated than that, mainly due to http URIs being used both as resource identifiers and as addresses for resources. A common case for the former are XML namespaces, those are not actually retrieved via the network, so http URIs are actually not a problem (on the contrary, changing them might confuse the code dealing with them). In the latter case the URIs are actually URLs and are used for network operations, those we need to fix.

Still, a bit of crude grep work can turn up quite some useful results already. This can be clickable links in code (D16904, R209:33447a) or documentation (D17262), downloaded content (D7414, D17223) or access to online services (D7408, D16925, D16946). But many hits are part of code documentation, automatic tests or license information (R1007:aff001), which are less severe in their impact. Sometimes URLs also appear in translations, so those would need to be checked too.

Compiled Files

Another place to look for http: strings is in the compiled binaries. That’s less complete, but seems to have a much smaller false positive rate. A simple approach is grep-ing through the output of strings and strings -l e (the latter decodes 16bit little endian Unicode strings as used by QStringLiteral), and filtering out common URIs as needed in the source code search too.

Runtime Monitoring

An entirely different approach for identifying clear text connections is observing network activity at runtime. Tools like tcpconnect of the bcc suite seems to be a good starting point, as it allows continuous monitoring without noticeable impact, unlike e.g. capturing the entire network communication with Wireshark.

With this we can also find non-HTTP connections, as well as entirely unnecessary network activity (D7410, D7438). However, we wont notice anything from code paths that aren’t run.


This is a perfect topic to get started with I think, fixing http: links is as easy as it gets, and yet that has relevant impact on the privacy or our users. But it doesn’t stop there, as we also need to build the tools to identify these issues more reliably. There isn’t much yet in terms of tooling, so a simple script would already be an improvement (e.g. to automatically check the KIO search provider desktop files), but if you are into elaborate runtime tracing techniques like used by the bcc tools, here’s a real-world problem to use this for :)

December 06, 2018

Cutelyst, a Qt Web Framework has upped to 2.6.0. This release if full of important bug fixes and is the best version when targeting Windows OS so far. It reached 5 years old, 440 stars on GitHub and since the last release has had many users asking questions, reporting issues and making pull requests.

Until now Windows support was a thing I mostly trusted Appveyor compiling and running tests fine, but this changed a bit in this release, I got a freelance job where some terminals would be editing images to be printed on T-Shirts, then they sent their art to a central server which receives and print, so, after I finished the QtQuick application and managed to convince them of running the terminals on KDE/Plasma as it was basically a kiosk full screen application I went on writing the server part.

Using Cutelyst on the server was a perfect match, the process was a Qt Widgets application, that, when linked to Cutelyst::WSGI could start listening all on the same process without issues, every terminal were connected via websockets protocol, which was just awesome, whenever I changed a terminal config I could see it changing instantly on the terminal, QWebSocketServer class could indeed do the same, but, to create the T-Shirt Art Fonts and Pictures needed to be “installed” on the terminal. Now with HTTP capabilities I simply exported all those folders and the whenever I sent a new JSON with config to the terminals, it contained the URLs of all these files which where updated in a blink.

On deploy time it was clear that using Windows on the server was a better option, first I’d need to give support for them on how to configure printers and use the system, also, printer drivers could also cause me troubles, so whatever let’s just compile it and get the money.

In order to make things easier I managed to get VCPKG to build a Qt5 for me, in a command line fashion, after that I saw how easy it was to create a package for Cutelyst, it’s upstream now, you just need to type:

vcpkg install cutelyst2

This will pull qt5-base package, and get you a working Cutelyst that easy, sadly Qt5 packages didn’t work on Linux nor on MacOS (both with issues filled).

Thanks to this project, several Windows related issues have been fixed, still work to do but I have an app on production on Windows now ��

I’m still no Windows fan, so I ended up configuring MXE and cross compiling Cutelyst and my application for Windows on Linux with it.

If you are doing embedded stuff, Cutelyst is also available on buildroot.

Besides that Cutelyst 2.6.0 has some other very important bug fixes.

Get it here!

It’s not uncommon to come across some dusty corner of KDE which hasn’t been touched in ages and has only half implemented features. One of the joys of KDE is being able to plunge in and fix any such problem areas. But it’s quite a surprise when a high profile area of KDE ends up unmaintained. is one such area and it was getting embarrassing. February 2016 we had a sprint where a new theme was rolled out on the main pages making the website look fresh and act responsively on mobiles but since then, for various failures of management, nothing has happened. So while the neon build servers were down for shuffling to a new machine I looked into why Plasma release announcements were updated but not Frameworks or Applications announcments. I’d automated Plasma announcements a while ago but it turns out the other announcements are still done manually, so I updated those and poked the people involved. Then of course I got stuck looking at all the other pages which hadn’t been ported to the new theme. On review there were not actually too many of them, if you ignore the announcements, the website is not very large.

Many of the pages could be just forwarded to more recent equivalents such as getting the history page (last update in 2003) to point to or the presentation slides page (last update for KDE 4 release) to point to a more up to date wiki page.

Others are worth reviving such as KDE screenshots page, press contacts, support page. The contents could still do with some pondering on what is useful but while they exist we shouldn’t pretend they don’t so I updated those and added back links to them.

While many of these pages are hard to find or not linked at all from they are still the top hits in Google when you search for “KDE presentation” or “kde history” or “kde support” so it is worth not looking like we are a dead project.

There were also obvious bugs that needed fixed for example the cookie-opt-out banner didn’t let you opt out, the font didn’t get loaded, the favicon was inconsistent.

All of these are easy enough fixes but the technical barrier is too high to get it done easily (you need special permission to have access to reasonably enough) and the social barrier is far too high (you will get complaints when changing something high profile like this, far easier to just let it rot). I’m not sure how to solve this but KDE should work out a way to allow project maintenance tasks like this be more open.

Anyway yay, is now new theme everywhere (except old announcements) and pages have up to date content.

There is a TODO item to track website improvements if you’re interested in helping, although it missed the main one which is the stalled port to WordPress, again a place it just needs someone to plunge in and do the work. It’s satisfying because it’s a high profile improvement but alas it highlights some failings in a mature community project like ours.

Facebooktwittergoogle_pluslinkedinby feather

KDAB announces the release of Kuesa™, a solution that provides an integrated and unified workflow for designers and developers to create, optimize and integrate real time 3D content in a 3D or hybrid 2D/3D software user interface.

Kuesa provides an easy, integrated and unified workflow without any compromises for designers and developers giving:

  • great performance on both desktop and embedded boards
  • high quality real-time 3D scenes
  • full expressiveness for designers, using professional 3D design tools
  • full control of integration for developers
  • reduced time to market.

For a practical demo, have a look at the tutorials created by KDABian Timo Buske, showing a complete workflow from the designer to the developer:

Kuesa is now available under both an AGPL and Commercial license. For more details about Kuesa and how to download it, visit the Kuesa web page.

Also, at this year’s Qt World Summit Berlin, KDAB’s James Turner will be giving a presentation on Kuesa titled, Streamlined Integration of 3D Content straight from 3DS Max and Blender into Qt3D. You can also view a demo of Kuesa at KDAB’s booth.

The post KDAB releases Kuesa™ for 3D asset creation and integration workflow appeared first on KDAB.

December 05, 2018

Since I find myself with a bit of down time. I have decided to update you all on the progress of atcore and atelier. We should hopefully be ready soon to start the process of releasing AtCore 2.0. I only have a few things I really want to get merged before I start that process. In the mean time here is what has been landed to AtCore since my last post.

  •  Allow for Reconnect without reset on unix hosts. (rizzitello, D13576)
  •  AtCore will now process Errors from the serialLayer (rizzitello, D15080)
  • Cleaned up Warnings from strict check. (rizzitello, D15861, D15701, D15280)
  • Allow for fractional movement. (i.e move X 6.84mm) (rizzitello, D15224)
  • New Axis Controller (rizzitello, D15281)
  • Use bit percentage for fan speed when needed. (rizzitello, D15700)
  • Use C++ Scoped enums (Cjlcarvalho, D16180)
  • Typo Fixes (yurchor, NO DIFF)
  • Header Typo fix (kbroulik, D17059)
  • Encapsulate the SerialLayer completely (rizzitello, D17146, D16200, D16199)
  • Fix Crash on reconnect on some cases. (rizzitello, D16616)
  •  Clazy Clang-tidy cleaning (rizzitello, D17101)

Atelier is getting more and more polish. Here is what has been landed to atelier since my last post.

  • Allow for Transforming Bed based on profile ( ervin, D16129 / rizzitello, D16144)
  • Check a file exists before attempting to print (laysrodrigues, D15122)
  • Remove Unaccelerated tooltips from lateral area (rizzitello, D16853)
  • Update new feeds as they are received (rizzitello,D16597)
  • QUrl.toString Not always valid (tcanabrava, D16002)
  • Clean up warnings (rizzitello, D16205)
  • Adjust icon size in lateral area for better scaling on a range of hidpi screens(rizzitello, D16855)
  • Prevent Error dialog if user cancels file selector (rizzitello, D17117)
  • Improve UI for mainwindow::askToSave(rizzitello, D17142, D17116)


December 04, 2018

Qt 5.11.3 is released today. As a patch release it does not add any new functionality, but provides important bug fixes, security updates and other improvements.

Compared to Qt 5.11.2, the Qt 5.11.3 release provides fixes for over 100 bugs and it contains around 300 changes in total. For details of the most important changes, please check the Change files of Qt 5.11.3.

Qt 5.11.3 contains the following important security fixes:

All these security fixes are included in the upcoming Qt 5.12.0 release.

Qt 5.9.7 released earlier contains all the fixes, except the one for virtual keyboard, which is available as a set of patches here, here and here.

Qt 5.6.3 release can be patched with these security fixes available here, here, here, herehere, herehere and here.

Qt 5.11.3 is the last release of the Qt 5.11.x series. The 5.11 branch is now closed. All bug fixes go into Qt 5.12 and the most important ones are cherry picked into Qt 5.9 LTS.

The recommended way for getting Qt 5.11.3 is using the maintenance tool of the online installer. For new installations, please download latest online installer from Qt Account portal (commercial license holders) or from Download page (open source).

Offline packages are also available for those can’t use the online installer.

The post Qt 5.11.3 Released with Important Security Updates appeared first on Qt Blog.

December 03, 2018

@tetris4 wrote:

Also available in Italian and Taiwanese Mandarin.

Hi everyone!

On your next system upgrade you will receive the latest versions of KDE’s Plasma, Applications and Frameworks, together with the regular package updates.

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

Other noteworthy package updates include:


  • ffmpeg 4.0.3
  • curl 7.62.0
  • openssl 1.0.2.q
  • apache 2.4.37
  • nginx 1.14.1
  • rust 1.30.1


  • steam
  • wine 3.21


  • filezilla 3.38.1

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.


Posts: 9

Participants: 6

Read full topic

As you might know, the QtQuick.Controls 1 module has been officially deprecated since Qt 5.11; this had been in the air already since quite some time, given that the development of the module had almost stopped. It looks like The Qt Company is mostly investing on the more performing QtQuick.Controls 2 module, and is inviting developers to switch over to that — at least for new projects.

However, there currently isn't a style available that would make an application using the QtQuick.Controls 2 look native on the desktop. There has been an attempt at it, but it soon turned into a custom style for the KDE desktop environment. So, some time ago I decided to give it a try: I started by forking the project of the KDE guys and as a first step I removed the dependency on the KDE libraries.

A button generated by the QML QQC2 desktop style
A traditional QPushButton
The difference (enhanced in Gimp, or you wouldn't see a thing)

It's a work in progress, and it probably has a long way to go before it's usable for a real world product, but I'm trying my best to turn it into something you can trust: this is a project where Test Driven Development fits very well, because in order to ensure pixel by pixel visual compatibility (that's my goal indeed!) I'm running a test where I create the same widget using the QtWidgets module and with this QQC2 style, and comparing the resulting surfaces for equality. In the pictures above you can see how the Button element looked earlier today (before I fixed it ��), compared to a traditional QPushButton: the test code creates a visual diff of the two images, and the test passes only if the resulting image is pitch black (with a very small tolerance for possible differences in font antialiasing).

For the time being I'm focusing my attention on the visual appearance of the individual widgets and their implicit size, but I'll soon add tests (and code) for layouts and interaction behaviours. I also need to extend the tests: they are currently run in GitLab CI for Linux only (where I can test the Fusion and the Windows styles), but I hope to find a way to run them in AppVeyor and on Mac OS. By the way, if someone knows of a CI service which would allow me to run my graphical tests on a Mac, please let me know in the comments.

This is an early notice that the project exists; if you have some time and energy to spare, you are very welcome to help me with the development.

Among the different cross-distribution application packaging systems available for Linux, the major ones being Flatpak, Snap and AppImage, I've chosen the latter for my own needs for the simple reason that it provides me the easiest way to ship my application and have it work out of the box. Flatpak and Snap will eventually get there, but for the time being universal availability and features like drag and drop are still to come.

However, the AppImage for PhotoTeleport is huge: due to having me ship many Qt5 modules, and especially the enormous QtWebEngine with all of its dependencies, the final package is almost 100 megabytes in size. One way to reduce that would be to require the user system to already have a Qt5 installation available, and therefore remove these libraries from the AppImage file. And if someone ran PhotoTeleport in a system where these libraries are not available, a small wrapper tool (based on xmessage maybe, and whatever Wayland equivalent exists) could inform the user of the problem and invite him to install the missing dependency. And I'm sure you certainly agree that this would be a horrible user experience: since we are so smart to tell that a dependency is missing, why not go the extra mile and install it ourselves?

Unfortunately, this “extra mile” is filled with subtle issues and there's the risk of delivering a solution that works in only a few lucky cases. For this reason, I would like to get the help of other developers and try to find a solution that takes into account all (or most) the subtleties that we need consider for different applications and target distributions. So, what follows is only the result of my initial brainstorming, and could be totally changed (or abandoned, if deemed unfeasible) depending on your welcome feedback.


  • Smaller size: indeed, this is the whole point of this effort!
  • Optional: we don't want to make life harder for all developers: if you are happy with the size of your AppImage file, you should continue to be able to produce it the way you do now, and users should be able to continue to install it in the same way
  • Easy but not magic: installing the missing dependencies should be easy, but should not happen without the user's consent. At the very least, we must check that an internet connection is available and make sure that the user is fine with us downloading the extra stuff we need.

The UI problem

No matter how the solution gets implemented, we can be certain of one point: we'll need a way to show some UI to the user. At the very least, this would be a dialog box or a wizard, which would inform the user of what we are doing. We need to find a solution that works both on X11 and Wayland, and that is small enough not to totally destroy the size gain. xmessage is probably present in every Linux distribution, but there doesn't appear to be a Wayland equivalent that is as much available (wlmessage even seems to be unmaintained). Of course, the possibility of shipping whatever tool we need in the AppImage itself always exists and is indeed in the philosophy of AppImage, but then we need to consider how much this costs in term of size.

On the other hand, AppImage packages already assume that some libraries are present in the target system: the excludelist file in the AppImages project lists those libraries. Among them we find the XCB library (to create surfaces on X11 systems) and FreeFont (to render font glyphs), which should give us the possibility of creating some UI in X11; the wayland client libraries are not included, but on the other hand we are talking of less than 100 kilobytes. The next question is whether we want just rely on these libraries, and therefore do all the drawing ourselves, or make use of some other drawing library which would make our task easier. A simple drawing library such as libcairo is already 1 megabyte in size, and if we move to a more complete solution such as Gtk or QtWidgets, the size grows considerably (something between 10 and 20 MBs, from a quick rough estimation). I don't have an answer to this question, and I'd like to spend some more time investigating other options before jumping to code the installer and drawing it pixel by pixel. :-)

The possibility of having different installers, depending on the UI toolkit used by the application shipped in the AppImage (so that most of the dependencies can be shared), should also be considered. This would of course reduce the size gain — for a Qt application, for example, we would have anyway to ship QtCore and QtWidgets because the installer needs them — and would introduce additional complexity because we'd need to make sure that indeed both the application and the installer can work with the version of the toolkit we are shipping.

The developer story

Let's put the UI issue aside for a while, and think about how this could work from the application developer point of view. We have a bunch of dependencies that we'd like to take out of our AppImage; for example, Qt 5.9 with QtQuick and QtWebEngine, and OpenCV. Ultimately, the information we need to pass to the installer is the exact name of the libraries (like,, etc.) as well as their soname as used by the application (like,, etc.), possibly an md5 signature for each of them, and the URL where we can get them from, in case they are missing from the user system. Writing this information is boring, so the AppImage project might store some ready-made configuration snippets in its git repository.

An additional simplification could be the creation of “frameworks”: bundles of closely related libraries (for example, have a QtBase framework containing QtCore, QtGui, QtWidgets, etc. with all their dependencies).

The user story

When the user installs our AppImage on his system and launches the application, this will first execute the installer: the installer will check that all the downloadable libraries declared by the developer are present on the system, and if any of them are missing it would show its UI and guide the user to install them (here I figure a wizard-like UI, with progress reporting and asking as few questions as possible). The libraries would be installed somewhere in the user home directory, without requiring admin rights.

The installer story

This is where all the magic would happen, and where all the dragons are hiding. It's hard to describe all the complexity in a coherent text, therefore I'll just write down a bullet list of whatever passes through my mind (it's a brainstorming, after all):

  • The downloaded libraries should be stored somewhere under the user's ~/.cache/ directory: the reason is that AppImage does not have an uninstallation procedure, and we've always been telling users that the way to uninstall an AppImage application is just to remove the corresponding binary. So, given that the user will not know that he has to remove all the downloaded libraries, the most polite thing we can do is to put them in the cache directory, and hope that if the system goes short on disk space, somehow the cache directory will be cleaned.
  • The installer will add the location where the downloadable libraries are expected to be installed (for example, this could be ~/.cache/appimage/lib/<app-name>/) to the LD_LIBRARY_PATH environment variable.
  • The installer will check for the library presence in the directory above, by using their soname; if all libraries are found, it will start the application.
  • If some library is not found, the installer will look for it in the parent directory, ~/.cache/appimage/lib/, this time without using the soname but the full name; if found, a symlink will be created in ~/.cache/appimage/lib/<app-name>/ linking the library soname to the actual binary library. For example: ~/.cache/appimage/lib/MyApp/libQt5Core.5 -> ~/.cache/appimage/lib/libQt5Core.5.9.
  • If the library is not found there, system locations could explored, too. And again, a symlink would be created in ~/.cache/appimage/lib/<app-name>/. The application developer should be able to configure the installer to skip this step, in case it's known that some target distributions ship a version of the desired library that is somehow incompatible with the app (because the distro has patched it in some unexpected way).
  • If a library is not found at all, the installer UI shall appear, to inform the user that some libraries need to be downloaded. As the user agrees to proceed, the installer will download the missing libraries.
  • Are either of curl or wget installed by default on every distribution? It would be simpler to use them from a shell script, instead of using libcurl from C.
  • The library must be made available online. The developer could do that on his own website, and/or the effort could be coordinated among AppImage developers to create and maintain common repositories for open source libraries.

The way forward

While this is a lot of work, I don't immediately see a great complexity or any real blockers. The thing that scares me the most is the idea of writing the installer UI without using any comfortable UI toolkit. Do you see some other big issues that I haven't covered?

While I put more thoughts into this, I'm tempted to start an effort to solve this problem for PhotoTeleport only: the easiest way would be to write an installer program with QtWidgets, which is already a dependency I'm shipping, and have the installer take care of downloading QtDeclarative, a few other QML modules and QtWebEngine. I could write it in such a way that it would be reusable at least for other Qt-based AppImages, and on the other hand this could be a proof of concept to tell whether this whole idea is feasible or not.

Just to highlight it: I wrote that I'm tempted to play with this idea; whether I'll do it for real is all another story. :-) I'm still pondering whether the whole thing is worth the effort, given that I haven't received a single complaint from users so far.

I already wrote about PhotoTeleport in my previous post, but since not everyone can comfortably read interlingua, here's the English announcement

I've spent the last few months of my free time to work on a new application, called PhotoTeleport, which is a photo uploader capable of working with multiple photo sharing services at once.

It's an application I myself felt the need for, because as a photographer I keep my portfolio in many websites: I have a couple of pages in Facebook, and VK (a.k.a. "the Russian facebook"), but I also have a profile in other websites such as Flickr and DeviantArt, which I created to further promote my activity, but which alas I failed to keep up-to-date. The harsh reality is that working with multiple profiles is hard: even if you had just two profiles to maintain, it takes a lot of time to upload the photos to both of them and, no matter how convenient their user interface is, entering captions, descriptions and tags here and there is another boring, repetitive and time consuming task.
Then how about automating it? Enter PhotoTeleport, and all photographers rejoice!

The program in itself is very simple: you drag and drop the photos into its window, select which services you want to upload them to, add captions, descriptions and tags (if you like), review and then upload. For those who prefer a feature list in bullet points, here it is:

  • Support many photo sharing services: DeviantArt, Facebook, Flickr, Google Photos, VK, etc. (see here for an updated list)
  • Album selection, or creation of a new album (if the service supports it)
  • Fast editor for captions, descriptions and tags
  • Possibility to specify different captions, descriptions and tags for each website
  • Read metadata embedded in the image files
  • On upload completion, provide a link to the newly uploaded files for additional editing or sharing

This is just a beta version, but more features are planned, including:

  • Ability to save and restore session
  • Watermark support
  • Image scaling
  • Support for more plugins (500px, Imgur, Smugsmug, Shutterstock, Photobucket, Pinterest and more)
  • Support for uploading to a custom (S)FTP server

You are indeed welcome to suggest new features, just by adding a comment to this blog post, or by creating an issue in the PhotoTeleport bug tracker.

PhotoTeleport is available for Linux, MacOS X and Windows; to get it, please visit PhotoTeleport website.

Only for the geeks and the folks from the IT crowd

Here's some info for those who desire to hack on PhotoTeleport, or just to know more about the technology behind id: PhotoTeleport is an open source project, it's written in C++ and QML using the cross-platform Qt framework. The authentication to the remote servers is handled by libauthentication, a library that I wrote just before starting the work on Phototeleport to provide an easy way for Qt and QML based applications to authenticate and peform authorized requests to remove websites using the OAuth 1.0 and OAuth 2.0 protocols (other protocols can be supported too).

Linux users might ask me why I chose to ship PhotoTeleport as an AppImage package, rather than using Flatpak, Snap or a native distribution package like deb or rpm. This might deserve a blog post of its own, but in brief:

  • deb> or rpm: they require root permissions to be installed, moreover PhotoTeleport uses Qt 5.9 which is not available in all distributions, so if I have to bundle Qt with my package, I don't see many advantages over shipping an AppImage;
  • Snap: they require root permission to be installed, and the support for desktop applications is still incomplete;
  • FlatPak: there's no runtime for Qt applications (and no, I don't want to force users to install the whole KDE runtime!), and drag & drop is not supported yet.

That said, it's just a matter of making the best out of my little spare time. I can reach every Linux user with the AppImage format, so that's the first option I took. I'm certainly open to the idea of using also other formats in the future (I might make debs after Ubuntu 18.04 is released with Qt 5.9) and I'll happily accept any contribution that can make PhotoTeleport available in Snap, Flatpak or other formats. But I don't have the time pioneering that right now :-)

Everyone who has used the QML programming language should love its property binding mechanism, which is made very easy to express via its declarative paradigm:

import QtQuick 2.0

Column {
  TextEdit {
    id: inputField
  Text {
    id: secondLabel
    text: "You typed: " + inputField.text

If you have worked on a project where QML was used along with C++ code, you might have bumped into a scenario where some bindings don't seem to work as you'd expect:

import QtQuick 2.0

Text {
  text: cppModel.get(row, "description")

  MyCppModel {
    id: cppModel

Whenever the value of the row variable changes, the property binding is re-evaluated and the text is correctly updated; however, if row is not changed and it's only the cppModel contents to change, then you'll be out of luck: the text won't update accordingly.
This apparently unexplicable behaviour has in fact an obvious explanation: the QML engine re-evaluates the property bindings only when a variable appearing in the expression (or in a javascript function used in the expression) is modified. But since in this case the function get() is a C++ method, the QML engine is not aware of this method's internals and does not see any change requiring refreshing the binding.

The first thing we have to do in order to solve this problem is to find a signal which tells us when it's time to re-evaluate the bindings. If you are working with a model derived from QAbstractItemModel, then you probably want to bind to the dataChanged signal, or maybe modelReset (if you simply reset the whole model when updating it). In the general case, your C++ class should have a signal or a property which gets updated when needed. If not, add it! :-)

The trick I've been using in some occasions is then to artificially trigger a change in a property used in the binding, in order to force the refresh:

import QtQuick 2.0

Text {
  text: cppModel.get(row, "description")

  MyCppModel {
    id: cppModel
    onDataChanged: {
      var tmp = row
      row = -1
      row = tmp

I know, I know, this is horrible. It works, but it causes the expression to be re-evaluated twice, since we are changing the row property twice. Besides, chaning the row property might have some unwanted side effects in other objects, if this property is used in other property bindings. And what if the C++ method doesn't take any parameters at all? How can we trigger its re-evaluation then?

I recently came up with another solution, which is the reason of this blog post. And yes, it's still a hack, but an elegant one. It uses the rarely used comma operator, which in Javascript works in the same way as in C++: it evaluates all operands, and returns the value of the last one. So, this is what we can do:

import QtQuick 2.0

Text {
  text: cppModel.updateCounter, cppModel.get(row, "description")

  MyCppModel {
    id: cppModel
    property int updateCounter: 0
    onDataChanged: updateCounter++

Note that we've added an extra property, updateCounter, which we'll change whenever we want the binding expression to be re-evaluated. In this case I've added the property to the QML component, but if you own the C++ object you could add it to your C++ object. And of course, if your C++ object already has a property which gets updated when you also want to update the binding, then you can use that instead: it can be of any type, it doesn't have to be an int.

I hope you'll find this tip useful. :-)
Mappero has always been distributed under a GPL licence. However, since when I started selling Mappero Geotagger (which is built from the same source), I decided not to publish the source code in a public repository, but only to provide it to those who made an explicit request to obtain it.

I spent some time reconsidering the matter, and I've finally decided to let the source code live in a public repository. I also setup a mailing list for it. And indeed I welcome code contributions, however there's a small catch: a CLA. While Mappero is distributed under the GPLv3 licence, I request that all contributors send me an e-mail in which they give me the right to re-licence their contribution under any licence published by the Free Software Foundation.

Since I believe that the busiest time for my involvement with speculo has passed, I expect to be able to spend some more time developing Mappero. The qt5 port is more or less working, but most of the cool features are missing, so it's little more than a map viewer at the moment (Mappero Geotagger, however, is fully working under Qt5!).

Here you can see Mappero running on an Ubuntu Touch powered Nexus 4. Pinch zooming and GPS are not yet working, but I promise they'll be there in less than a week. Also I found a nasty bug which can cause the application to crash when downloading map tiles, and I'll fix it ASAP (I'm mentioning it just so that I won't be flooded with identical bug reports now :-) ).
Io es felice de annunciar que io ha publicate QtRaw, un plugin que permitte a tote programmas que usa le librerias Qt (e consequentemente, QML) de aperir e visualisar imagines in formatos raw; istos es le imagines producite per multe photocameras digital professional e semi-professional.
Si on vole visualisar le imagine in un formato reducite, le plugin utilisa le imagine de prevista (thumbnail), lo que es multo rapide.

E nunc io va; le prandio de Natal me attende. :-)

I decided to blog about my experience of transitioning from being a GLib and GObject enthusiast to a Qt (and QML) fanboy. :-) I'm not writing this with any specific goals, other than sharing my own experience and hopefully making the life of those developers who are forced to learn and use Qt less painful and a bit more rosy; in particular, I'm not trying to be a Qt evangelist here and convince you, hardcore GObject developer, to switch to Qt: I'm indeed sure that if my current self tried to talk my 3 years younger self into Qt, it would be a useless and tiresome (and maybe violent ;-)) discussion.

Just a bit of background on myself: I've been developing on Linux and Unix for more than 10 years now, mostly using GObject based libraries, such as Gtk+. I had a short encounter with Qt in about 2004, just for a few weeks, which left me with a bad impression (mostly because of the uic). Other than that, I was simply not interested in Qt, mostly because I hate C++ and love C and anyway all my needs were perfectly met by GLib, GObject and Gtk+. I remember that the first time when I read about GObject, I was fascinated: the power of OO programming on top of my favorite language, all open source and hackable. In autumn 2006 I started a new job in Nokia, in the maemo team, working on a middleware component in the Telepathy VoIP framework; I enjoyed it a lot, and (if possible) grew even more fond of GObject and GLib. On early 2008, the big news: Nokia acquires Trolltech (the SW house developing Qt); for me, as for most of the people working in the maemo team, this came as a complete surprise, and not as a really good one. Indeed, we were afraid that we would have to abandon the C/Gtk+ work and switch to C++/Qt — perhaps not coincidentally, several GNOME developers working in Nokia even left the company around that time. Luckily though, nothing really changed for us for more than one year, and even later, when more people joined to work on Qt-related stuff and I moved to another project, I could still avoid touching Qt code and continue using only my beloved GObject. However, like all good dreams, this also came to an end: eventually, I had to refresh my C++ knowledge and change my most typed character from "g" to the hated "q".
So, here my Q story begins.

The first prolonged exposure to Qt

It was painful. My first task was to create Qt-bindings for the GLib-based library I was developing. There was no UI involved, so on the tools front the experience was not as bad as I remembered; but on the pure programming side, I was horrified: I felt extremely limited, many programming paradigms I was used too couldn't be applied, or I was just told (by people more expert in Qt) that “you shouldn't do like that, it's not the Qt way!”. Urgh.

The biggest issues I had were the lack of reference counting in QObject (!!) and the veto on using C-style function callbacks for asynchronous operations (you should use Qt slots, and in order to have a slot you must have a receiving QObject). How could I take Qt seriously? Sure, there were also a few nice things about it, like the fact that QObject comes with child-parent lifetime handling out of the box (when a parent object dies, all of its children are automatically deleted), and that signal connections are automatically broken when either the emitter or the receiver object dies (yay, no more explicit signal disconnections — or random crashes!). But still, this could in no way compensate for the lack of the other low-level features I was used to.

I cannot really say that I enjoyed the first months of using Qt. I was still trying to work as much as possible on the GLib-based parts of the project, and twisting my head around to figure out what was “the Qt way” of doing all the things that I was used to do almost instinctively with GLib/GObject.

From hate to love

Now that I think back and try to find the moment of time when I finally started liking Qt (or just not dislike it too much), I cannot really point out a definite time. It was a very slow process, that surely wouldn't have completed if I hadn't been forced to use Qt because of my work. But indeed, the moment when I realized that Qt was not so bad after all is when I started writing new original code with it. In retrospection, I would say that my experience with Qt was so bad because I started with a completely wrong task: as an inexperienced Qt developer, creating binding for a GObject-based library couldn't possibly make me appreciate Qt; I was just bound to notice all the GObject features that were not present in Qt, and suffer their absence. And I wouldn't notice almost any of the niceties that Qt offers to application developers, because there is not much code you can write in a wrapper library other than some trivial glue code.
So, my first suggestion for those GObject developers who start using Qt is: do not write a Qt wrapper to your favorite GObject library!, you are going to hate it. Leave it to someone who is more experienced than you in Qt; it can be a very pedagogic task, indeed, but chances are that it will be the last time you are going to use Qt. If you can, start with writing new code.

That said, there is a big difference between not disliking something and loving it. But again, I cannot tell when I started loving Qt. What I surely can tell is when I realized that I loved it: and that was when I started porting some GObject-based code to Qt (not as a line-by-line port, but more like a functional rewrite) and found out that the resulting code was not only more compact and easier to write, but — and especially — easier to read. And of course, when I realized that my enthusiasm was not the same as before, whenever I had to do some programming in C+GObject.

What I find cute in Qt

Let me begin with a couple of statements which could dispel some myths or anyway clarify some doubts that the Qt-virgin might hold:

  • It's not C++. This is a bold (and false) statement, but it's probably the most effective to convey the idea: if you — like me — hate C++, you won't necessarily hate Qt. Qt's C++ is a subset of C++: although you can use whatever C++ feature you might like, developing with Qt does not involve using exceptions, templates, RTTI and the STL. In a similar way to how GLib and GObject “extend” the C language, Qt uses a preprocessor (called moc) to add its own run-time type information (think of GType) and implement the signals/slots mechanism. In the end, you don't need to know all the details of C++ to develop Qt; instead, it's somehow similar to developing Vala code — it's like a programming language of its own.
  • It's not just GUI. As you might have noticed, this post is not about Qt vs. Gtk+, not at all. There are many other articles on the web where you can find comparisons and opinions of the two, but what I'm focusing on here is my experience with Qt programming and GNOME programming, and not just at the UI level. So, yes, the point is that you can develop whatever code with Qt (except maybe kernel drivers): I've personally written D-Bus services, command line tools and embedded software using just Qt.
  • There really is a Qt way. My disappointment about the lack of reference counting in QObject is now history: apart from the fact that indeed there is one class in Qt which lets you implement reference counting for QObjects, I cannot recall any case where reference counting would have been useful. I know, coming from GObject this might sound hard to believe (especially to my three years younger self, who used to mess up with cross references everywhere in the code), but it's a fact: after some initial struggle, I always managed to design the software with clear ownership of objects, so that the reference counting ended up to be totally superfluous. And in fact, my code is designed better now. The same can be said of any other feature that I initially missed: if it's not there, you can do without it: just restructure your code in a different way — the Qt way — and there's a good chance that while reworking your classes you'll clear up some mess. :-)

That said, here's a list of things that I came to like about Qt; I'm obviously not mentioning those things that are also in GLib/GObject, unless there are significant differences.

  • QObject automatic destruction of children. I already mentioned it before, but it's worth expanding a bit. Quite often I had to use reference counting in my GObject subclasses to keep track of the child-parent relationships; QObject already does that for you: whenever you create a QObject, you can specify one parent object which will “watch” its lifetime and destroy it in its destructor. This leads to a nice programming paradigm where you can create all the objects that your class needs and just use the this pointer as parent object: then you don't need to remember destroying them explicitly in your destructor.
  • Automatic disconnection of signals when receiver object dies. I also mentioned this before, but repetita iuvant: if you are an experienced C + GObject developer, you must have seen at least once in your programming career one crash due to a signal callback invoked when the objects it operated on had already been destroyed. Of course I know that it never happened to you personally, but you surely saw this in someone else's software. ;-) Well, in Qt this is very unlikely to happen, because (at least till Qt4) it's impossible to bind signals to C callbacks: you must bind them to a QObject method (called “slot”), and the QObject system takes care of disconnecting the signal for you when either the emitter or the receiver object are destroyed.
  • QString. I'm sometimes a bit maniacal with micro-optimizations, and one thing I was always trying to optimize in my early GLib days was avoiding string allocations. It really hurts me to write a g_strdup() in a library method's implementation when I could rather write "Please, don't destroy or change @string_param while this object is still alive" in the documentation string for the method. But that's not the GLib way (and indeed, not my way anymore when I write GLib code): you can never know what happens with the string, so it's way safer to incur the small penalty of a g_strdup() than run the risk of a crash which is likely to be very hard to debug. So, C/GLib code is often full with g_strdup() and g_free() (not to speak about valac-generated code!). Enter QString! QString is not only a class that provides a ton of useful string methods, it is an implicitly shared class. That means that the QString structure itself is very small (size of a pointer?), and that the string data is reference counted; then if/when you modify a string which has a reference count higher than 1, the string data is copied and your QString is now pointing at the modified copy. So you never have to worry about copying strings! How cool is that? :-)
  • Awesome container classes. Qt comes with a few container classes which you'll surely get to like: QMap, QList are those that you'll use the most, but then there's also QSet, QQueue, QHash, QVector and others. These are template classes, so you can write QMap<QString,QVariant> and get the equivalent of a GHashtable whose keys are strings and values are GValues. Inserting items is as easy as writing
    QMap<QString,QVariant> map;
    map.insert("string", "string value");
    map.insert("integer", 12);
    while to iterate the values you have the handy foreach macro, which lets you write
    foreach (const QVariant &value, map) {
        QDebug() << "Value:" << value;
    And if you remember what I wrote above about QString: Qt container classes are implicitly shared too!
  • Reduced usage of pointers. This follows in part from the above: QString handles all string pointers for you, and the ease of implementing implicit sharing of container classes makes it so that you will be often passing them by value or by reference. Also, implementing implicit sharing for your own data structures is very easy, and you might prefer investing a little time doing that rather than using raw pointers.
  • Class and API offering. Even excluding the GUI classes, the functionality provided by the Qt classes will satisfy the most demanding developer: whether you want to deal with date/time, with network resources, with graphics/images, HTML (webkit), SQL databases, D-Bus, plugins, regular expressions, etc., it's all there, and everything works perfectly together. The APIs are intuitive and clean: you won't find duplicate classes offering the same functionality (unless one is deprecated), and the documentation is excellent.
  • Compact and clean code. Qt application code is likely to be much mode compact and clean than GObject code. Just like Vala, imagine removing all GObject casts and using class namespaces to shorten your method names and fit your code in a 80 chars wide editor. :-) Use const effectively to mark your class methods and finally be able to pass constant objects and structures around your code, minimizing the risk of incorrect usage.
  • QML. This would deserve a chapter on its own, but since there has been quite a lot of buzz around it on the internet I won't spend many words on describing it. Instead, I'll focus on how I came to like it so much. As it often happens with new things, my first impression was not so great; sure, all the QML demos you can find in the internet are extremely captivating, and it's impressive how much you can achieve with very little code — which doesn't even look like real code, but more like a static description. And this was indeed my first doubt: what is the limit of QML? It's a nice language for moving graphics items around, but does it let me do anything more than that? Or: if it really allows me to write complex UIs for big applications, won't the code become a horrible mess to maintain? Again, time and hands-on experience is what changed my mind. I'm porting one map application from Gtk+/Clutter to Qt and of course the map widget and its animations has been my first item in the list. Clutter is a fantastic toolkit for producing animated UIs in the GNOME world; the Qt equivalent is QGraphicsView, whose APIs luckily match very close the Clutter ones; so, the porting wasn't that difficult at all, and it didn't took long until I had my widget working. However, for implementing the animations (zoom, panning and rotation of the map) I didn't use the Qt Animation Framework, which would be the natural equivalent to Clutter animation classes, but instead went for QML: exposing the map properties to QML enables implementing animations in a much easier and enjoyable way. QML property bindings, together with property animation descriptions, empower your application to any kind of smooth animations with almost no effort on your side. You don't have to take care of starting/stopping animations, changing the direction of animations while they are running, or combining zooming/panning/rotation at overlapping moments: no matter how crazily the user plays with your UI, all animations happen as expected, without any need for you to special code them. I couldn't help falling in love with QML. :-)
    So, my answers to the above questions are that, first of all, QML is a language especially designed for developing UIs and UI logics. There's not much else that you can do beside that; in order to write algorithms and implement the rest of application (all what is non-UI) you have to resort to either Javascript or C++ (or Python, etc.); the only difference on how you use these languages is that it's possible to write the Javascript code in the .qml file itself, which is very convenient but also, in my humble opinion, something that you shouldn't do. So, while you could say that it is possible to write an entire application in QML, I heartily discourage you from doing so; if you really like Javascript (why would you, by the way?) and want to write your application with it and QML, it's much better to write the code of your application logic in a .js file and import that from QML. About QML code becoming a maze when writing complex applications, I disagree; of course, it's possible, but it's the same in all other languages (which I know of). If you split your code into smaller QML files (per UI component or groups of components) and avoid creating cross dependencies between components, everything will go smoothly — my golden rule when writing QML code is that a .qml file should never refer to identifiers which are not defined in the file itself. The reason why I'm getting so down in technicalities here is that, if you are a developer who has some experience with QML but finds it messy, you should go and check your code against this rule. :-) Indeed, QML is not a panacea which let everyone who is not a developer write über-complex applications; it's easier and more effective than all other languages (which I know of, again), but the rules of good software development still apply.

How you can start liking Qt

No way you will. ;-) Joke aside, there is some truth in that answer: first of all, you will never like Qt until you try it; and you won't try it unless you are forced to, or have some very good reasons to start looking into it. In my case, in fact, I was forced to, and — at that time — I had absolutely no reason to try Qt on my own: I already had some bad memories with it, I didn't like KDE, the skype Linux client and, most importantly, I was totally happy and satisfied with coding C and GObject.

However, I believe that nowadays there might be two reasons why even a hardcore GNOME developer could, in an unforgivable moment of weakness, decide to try programming with Qt: QML and application portability. QML is the new cool stuff (it was not there when I started with Qt), there are plenty of nice demos and examples out there, and they do pretty amazing things. Especially given that setting up the environment is an easy task (just install the Qt packages from your Linux distribution) and running the demos is in most cases just a matter of typing qmlviewer <file>.qml, and that you are a very curious geek, it's not so unlikely that you'll want to have a closer look to the demos; and since the source code consists in most cases of just a few lines of JSON-like text, it won't take long for you to understand it and maybe start playing with it. Especially because I still believe that GNOME developers deserve something as cool as QML. :-)
The other reason why trying Qt nowadays is not so absurd as it might seem is portability. Yes, Qt has always made portability his flag, but who does really care about Windows and Mac? However, what you might care about is Android! What has changed here in the last couple of years is that Qt and QML run on Android, with GL acceleration and multitouch support, enabling you to develop modern applications which can be run on millions of devices; you can also target the best smartphone ever, Symbian smartphones and whatever devices Nokia will come up with for the next billion.

I don't think there is much more I can write to stimulate you to try out Qt or, if you have already started using it, to support your efforts to master it. What I can tell you, with no fear of being contradicted, is that eventually you will like it; there is no way that this won't happen, if you continue learning it. At some point you will realize that going back to C (or even Vala) and GObject is not going to make your programming more productive, or even more enjoyable than how it has become with Qt. It's just a matter of enduring the difficulties and unpleasantness for a long enough time; which can be even several full months if you are, like me, one who takes technologies, programming languages and libraries next to your heart.

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.