Subscribe to Planet KDE feed
Planet KDE -
Updated: 9 min 8 sec ago

KDE Bugsquad – Kdenlive Bug Day on December 15th, 2018 (Today!)

Sat, 2018/12/15 - 12:23pm

We will be holding a Bug Day on December 15th, 2018, focusing on Kdenlive. 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!

Stable: not moving vs. not breaking

Fri, 2018/12/14 - 5:13pm

There are two terms that brings a heavy controversy in the Open Source world: support and stable. Both of them have their roots in the “old days” of Open Source, where its commercial impact was low and very few companies made business with it.

You probably have read a lot about maintenance vs support. This controversy is older. I first heard of it in the context of Linux based distributions. Commercial distribution had to put effort in differentiating among the two because in Open SOurce they were used indistictly but not in business. But this post is about the adjectivet stable

Stable as adjective has several meanings in English:

  • According to the Cambridge dictionary stable is, among others: firmly fixed or not likely to move or change. I am used to this meaning because of my backgroun in Physics.
  • One of the definitions provided by the Oxford dictionary is slightly different: not likely to change or fail; firmly established.

Can you see the confusion between…?

  1. It is hard to move… or move slow.
  2. It does not fail… it is hard to break.

I am not an English native speaker. Maybe because of its latin root (I am Spanish) or maybe eacuase I studied Physics, I do not provide to the adjective stable the second meaning. It has always called my attention how many people provide both meanings to the word, specially when referring to software releases. Looking at the dictionaries, I can tell why in English there is such link between both ideas.

I read today on Twitter another example of this confusion/controversy. The comment has its roots on a different topic but it has embedded this confusion, I think.

Open Source projects used to have as the main testing strategy the collaboration with a group of beta testers and power users. This strategy helped to create this relation between “not moving” and “not failing” that has become so popular. But this relation is not direct if you have a different release/deploy strategy. The way to increase stability (as hard to break) is by detecting and fixing bugs and that can be done moving fast (constantly updating), or moving slow (backporting). I will not get into which one is better. Both are possible and popular.

I think the word stable should be avoided. Many system and application developers or integrators refer to it as “move slow” as “it will not change much“. But what many users hear is “it will not break” which is why “it moves slow“.

Which adjective can we use to label a release that “moves slow“, so it is not mistaken with “it is not expected to break“?

Is this controversy present in other languages as strong as I perceive it in English? Is it just me who see this controversy?

My new gravatar

Fri, 2018/12/14 - 5:00pm

More and more applications invite you to add a pic in your profile, a gravatar. In some applications and specially in social media the size and position of these gravatars are becoming prominent, too much for my taste. I am not a fan of pictures, I have never been. I do not like selfies, I have no Instagram, I try to avoid publishing pics of myself on Facebook… .

I use two different gravatars in internet. One for professional profiles and applications, associated to my corporate account ( nowadays ), which was taken about 4 years ago, and one I took over 10 years ago associated to my personal account. I have hair on that one.

A few months back I started to think about my approach to this gravatars, looking for something simpler that could last, reflect my personality and that could be used for both, personal and professional profiles… and substitute the pic I have in my site.

My first idea was to ask a couple of photographers I know to take a good picture of me. One of those super modern, super cool, super fancy I-enjoy-life-you-should-ping-me-and-I-will-teach-you-how-but-only-if-you-are-cool-enough-to-deserve-my-coolness kind of picture. I was not fully convinced on this approach though. It would only work if the pic is really cool and checking LinkedIn, I had little confidence my pic could be at the level of some of my connections. Yep, I am connected to very cool people.

Then, looking at some gravatars from hackers I know who have zero interest in publishing a pic of themselves, I thought that maybe an illustration could work. Something simple, not a portrait. An illustration that looked like me but is not me, that could work in small and medium size formats… .

Exactly, I did not know what I want. It was more like… I do know a few things I do not want.

With this “crystal clear” idea, I contacted Ramón Miranda.

Ramón is a professional illustrator that has contributed to several Open Source projects, like Krita. He lives only a few kilometres away from my place in Málaga, Spain which is… great.

I explained him in a mail my idea. We have a video chat to polish the concept and a few days later he invited me over his place to show me a draft. A few days later my new representation of myself was done… with Open Source tools (Krita). And yes, I have the source file.

toscalix avatar

Thank you Ramón for accepting the challenge and for your dedication. I like the result… a lot. Do you?

Yep, I will erase you comment if you don´t.

If you ever need a professional illustrator consider pinging Ramón. He is a hell of a professional. Ah, and he provides online training sessions for those wanting to learn or improve how to draw/paint in the analog and in the digital world (with Open Source tools).

Time to substitute my pics with this new gravatar.

18.12 release and some news

Fri, 2018/12/14 - 4:12pm
18.12 release
Kdenlive 18.12 is out. In this version we have fixed some crashes and made some other improvements. 
18.12 release notes
  • Backport crash on image sequence import. Commit.
  • Backport fix for titler text gradient. Commit.
  • Add donation url to appdata. Commit.
  • Fix minor EBN issues and typos. Commit.
  • Fix play/pause on Windows. Commit.
  • Sync quickstart manual with UserBase. Commit.
  • Install doc files. Commit.
  • Make it compiles when we use QT_NO_NARROWING_CONVERSIONS_IN_CONNECT. Commit.
  • Fix minor EBN issues. Commit.
If you were waiting for the refactoring version, we’re afraid you’ll have to wait a bit longer. We decided to postpone it for the 19.04 release cycle which will give us more time to polish all the edges and add some new nifty features. 
  •     We now have a nightly build system so you can try all the latest features;
  •     Among the highlights since the last release;
  •     Added parallel processing feature for render speed improvements;
  •     Added hardware acceleration for proxy clip creation;
  •     Blackmagic Design decklink output is back;
  •     The Speed effect has been reintroduced;
  •     Made keyframe improvements and timeline clip keyframeable GUI.
Please help us test and report your feedback in the comments. Get it!
In other news 
After the bug squashing day an interested developer joined the the team and is fixing MOVIT (GPU effects) support. We are very happy to see more people interested in contributing code to the project. Check out our Junior Jobs list and send your patches.
On the Windows front, we have implemented many improvements, among them the hanging process on exit is fixed but more on that next week. ��
The team has also started brainstorming the interface redesign. You can follow the progress (and contribute) in this refactoring task.

What’s new with the Wayland platform plugin in Qt 5.12?

Fri, 2018/12/14 - 11:30am

Wayland is a display server protocol used on modern Linux systems, the Qt Wayland platform plugin lets Qt applications run on Wayland display servers (compositors).

Continuing the trend from the Qt 5.11 release, the Qt 5.12 release contains a substantial amount of improvements.

Window decorations
Old window decorations

Old window decorations

We’ve received quite a few complaints about the looks of our window decorations over the last few years. The message is usually: “They are ugly and don’t look native.”

On Wayland, window decorations are supposed to be drawn by the client by default. Consequently, Qt’s window decorations will probably never look identical to what other toolkits draw. I.e. there is no “native” look with client-side decorations. That is, however, no excuse for them to be ugly.

In 5.12, I’ve updated our default decoration plugin so it looks like something from this decade. It still won’t be “native” looking, but it looks closer much closer to what the other toolkits draw.

New window decorations

New window decorations

The default window background color is now used for the decorations, so it should follow your Qt theme quite nicely.

Window with dark theme

Decorations follow the theme of the window.

Furthermore, we’ve now also added support for support for the Wayland extension, xdg-decoration unstable v1. Compositors implementing this extension can now tell Qt clients that decorations will be drawn server-side instead of client-side. I.e. the decorations for Qt applications and other toolkits can be identical after all. This is also good news for people running tiling compositors. It’s no longer needed to set the environment variable QT_WAYLAND_DISABLE_WINDOWDECORATION on compositors that implement this extension. Toggling window decorations at runtime is now also possible.

server-side window dsecorations

The server-side-decoration QtWayland Compositor example. The bar at the top with the close button is drawn and handled by the compositor.

xdg-shell stable

On Wayland, the shell extension is the part of the protocol that gives meaning to surfaces, i.e. it communicates things like: This surface is a popup-menu, this is a toplevel window, this is its window title and application id, this is how it should be maximized, resized minimized etc.

In other words, a pretty important part of the protocol. The problem is that, while Wayland has been stable for many years, there has been no stable shell extension for the desktop. wl-shell is considered deprecated, and development has continued with the unstable xdg-shell. Unstable protocols have backwards incompatible changes in every release, this means that when a new version is released, it’s essentially a new, although similar, protocol. If we were to simply update our code to the protocol described in the new version, Qt clients would stop working on compositors not supporting the new version.

We’ve solved this by using a plugin architecture for loading a shell integration at runtime depending on what the compositor supports. In other words, each time a new breaking version of xdg-shell is released, we create a new plugin for it. The exciting news this time, is that xdg-shell finally turned stable in December last year, and with it broke backwards compatibility for the last time.

Consequently, Qt 5.12 adds the last and final shell plugin for xdg-shell. This means we can finally deprecate the old unstable xdg-shell plugins and concentrate on making the one stable plugin great.

High DPI cursors

Giant cursor

Support for high DPI cursors has been added. Cursors are now also loaded lazily to significantly reduce the memory footprint on embedded devices that don’t really need them.

Handling maximization and fullscreen on xdg-shell

Implementing fullscreen and maximization properly on xdg-shell required a huge refactor in how resizing works in Qt Wayland. That refactor is now in place, and Qt applications on all supported versions of xdg-shell should now properly switch between fullscreen, maximized and windowed mode.

Forcing a logical DPI of 96
window with tiny fonts

Sometimes compositors report 1px=1mm (a DPI of 25.4) when they don’t have better data available, causing physical DPI to be unreliable.

Quite a few things in Qt depend on the logical DPI, most notably point sized fonts. Previously, we’ve calculated the logical DPI using the physical size and resolution of the screen. This works great in most cases, but sometimes the physical dimensions that compositors provide are wrong, which usually results in tiny unreadable fonts. So in Qt 5.12, we switched to forcing a DPI of 96 by default. The old behaviour can still be restored by setting QT_WAYLAND_FORCE_DPI=physical in the environment.

Fractional scaling

Support for xdg-output unstable v1 was added. It’s a protocol extension for communicating additional information about screens and is needed to implement fractional window scaling on the compositor side. Read the details in David Edmundsons blog post.

The post What’s new with the Wayland platform plugin in Qt 5.12? appeared first on Qt Blog.

How to create QBSPs from Yocto builds

Fri, 2018/12/14 - 7:00am

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 QBSP_IMAGE_CONTENT = "\ ${IMAGE_LINK_NAME}.img \ ${IMAGE_LINK_NAME}.conf \ " qbsp.bbclass

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_INSTALLER_COMPONENT = "embedded.b2qt.${VERSION_SHORT}.yocto.${QBSP_MACHINE}" QBSP_INSTALL_PATH = "/${PV}/Boot2Qt/${MACHINE}" 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.

Achievement of the Week

Thu, 2018/12/13 - 6:41pm

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

Krita 4.1.7 Released

Thu, 2018/12/13 - 9:03am

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)
Download Windows

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 md5sum

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.

A simple blank makes the difference

Wed, 2018/12/12 - 7:54pm

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.

Calamares seeking translators

Wed, 2018/12/12 - 8:53am

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.

SSL Certs on my sites

Tue, 2018/12/11 - 2:44pm

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.

ROOT histograms

Tue, 2018/12/11 - 10:21am

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.

QtCreator CMake for Android plugin

Tue, 2018/12/11 - 10:00am
Santa Claus is coming to … wait a minute, it’s not Christmas yet!

I have the pleasure to let you know that KDAB has contributed to Qt with yet another super cool project!

It’s about QtCreator CMake for Android! I know it’s a strange coincidence between this article and The Qt Company’s decision to ditch QBS and use CMake for Qt 6, but I swear I started to work on this project *before* they announced it &#55357;&#56898; ! This plugin enables painless experience [cut from here] well, painless experience and cmake in the same sentence is a nonsense[/to here] when you want to create Android apps using Qt, CMake and QtCreator. It’s almost as easy as Android Qmake QtCreator plugin! The user will build, run & debug Qt on Android Apps as easy as it does with Qmake.

Before I go into the boring details, let’s see what the requirements are and, more importantly, when it will be available!


  • cmake 3.7 or newer (needed for server support in QtCreator)
  • NDKr18 or newer (only Clang and libc++ shared are supported)
  • Qt 5.12.1 (was too late for this patch to get in 5.12.0)

When will it be available? Well, I started the blog with the Santa on purpose, because, sadly, it’s too late to push it in QtCreator 4.8 and it will be available in the next version (4.9). If you can’t wait for QtCreator 4.9 and you like to try it sooner, you can apply this patch on top of QtCreator’s master branch.

Now back to technical details, in order to build your Qt Android application, this plugin must do some magic:

  • after it builds the C++ bits, it copies all the targets (DynamicLibraries) into “{build_folder}/android/libs/{arch}”
  • generates android_deployment_settings.json, which is needed by androiddeployqt tool

After this step, androiddeployqt will complete your Android Qt APK by copying all the Qt dependencies (libs & resources).

Last but not least, these are qmake features that you’ll not find in cmake:

  • IDE management for ANDROID_PACKAGE_SOURCE_DIR yes, it supports even the same naming as qmake. You’ll need to add the following piece of cmake script to your CMakeLists.txt file: if(ANDROID) set(ANDROID_PACKAGE_SOURCE_DIR "${CMAKE_CURRENT_SOURCE_DIR}/android" CACHE INTERNAL "") endif()

    The CACHE is mandatory, otherwise QtCreator won’t see the variable and it won’t use it

  • IDE support ANDROID_EXTRA_LIBS, you’ll need to add the next piece of CMake script to your CMakeLists.txt file if(ANDROID) if (ANDROID_ABI STREQUAL "armeabi-v7a") set(ANDROID_EXTRA_LIBS ${CMAKE_CURRENT_SOURCE_DIR}/3rd-party/android_armeabi-v7a/ssl/ ${CMAKE_CURRENT_SOURCE_DIR}/3rd-party/android_armeabi-v7a/ssl/ CACHE INTERNAL "") endif() endif()

    The previous snippet will add and files ONLY for armeabi-v7a android ABI.

Note: KDAB offers training in CMake, including all the latest tips from our trainers, who are all active developers.

The post QtCreator CMake for Android plugin appeared first on KDAB.

KDE4 and Qt4 deprecation in FreeBSD

Tue, 2018/12/11 - 8:19am

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.

Two printers with one Rpi?

Mon, 2018/12/10 - 12:00pm

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.

QtWS post (-scriptum)

Sun, 2018/12/09 - 10:15pm

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!

Release month, qpropgen 0.1.1

Sun, 2018/12/09 - 10:22am

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 properties: - 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_OBJECT 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 ) public: 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); signals: void firstNameChanged(const QString& firstName); void lastNameChanged(const QString& lastName); void birthDateChanged(const QDateTime& birthDate); private: 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) { return; } mFirstName = value; firstNameChanged(value); } QString Person::lastName() const { return mLastName; } void Person::setLastName(const QString& value) { if (mLastName == value) { return; } mLastName = value; lastNameChanged(value); } QDateTime Person::birthDate() const { return mBirthDate; } void Person::setBirthDate(const QDateTime& value) { if (mBirthDate == value) { return; } mBirthDate = value; birthDateChanged(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, part 48

Sun, 2018/12/09 - 7:01am

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.

Finding insecure network connections

Sat, 2018/12/08 - 12:15pm

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

Cutelyst 2.6.0 released! Now on VCPKG and buildroot

Thu, 2018/12/06 - 6:26pm

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 &#55357;&#56898;

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!