January 17, 2018

Como comenté hace poco en un artículo dedicado a Kamoso, la convergencia ha empezado y nada va a detenerla. Este año uno de los temas recurrentes en el blog será la adaptación de muchas aplicaciones a este nuevo tipo de tecnología donde una misma aplicación servirá para todo tipo de dispositivos. Así que me complace compartir con todos vosotros que Babe migra a Kirigami, una gran noticia para el reproductor multimedia Babe, una aplicación que tiene un aspecto excelente y mucho futuro por delante.

Babe migra a Kirigami, un gran paso para el joven reproductor multimedia

Conocimos esta aplicación en Akademy 2017 de Almería. Incluso tuvimos el gusto de hacer una pequeña entrevista a su creador,  Camila Higuita, y que fue publicada en el canal de youtube de KDE España.

Se trata de Babe Music Player, una aplicación musical que pretende mantener siempre a tu disposición tus canciones favoritas, bien sea de tu disco duro o de tu servicio de internet favorito, gracias a las diversas fuentes con las que puedes alimentar la aplicación.
La noticia es que ha iniciado su migración a QML utilizando la tecnología Kirigami para que sea convergente. De hecho, el mismo Camilo nos presenta su trabajo inicial en el siguiente vídeo.

Y no contento con eso, un par de días más publicó otro con una visión mucho más avanzada de la aplicación.


¿Qué ofrece Babe Music Player?

Las características generales de Babe Music Player son las siguientes:

  • Posibilidad de filtrar por artista, título, álbum, género, fecha o localización.
  • Añade tus canciones favoritas de youtube utilizando la extensión para Chromium
  • Varias formas de visualizar tu lista de reproducción: Mini, Playlist  y modo collection.
  • Menú contextual con información sobre la pista reproducida
  • Integración perfecta con el escritorio Plasma: notificaciones, controles mpris, interacción con kde connect y control vía acciones de krunner.

Babe migra a Kirigami, un gran paso para el joven reproductor multimedia

¿Qué es Kirigami?

Kirigami esa plataforma de desarrollo open source multiplataforma basado en Qt con el que se pueden crear aplicaciones que, evidentemente, funcionen en multitud de dispositivos. Es decir, aplicaciones que funcionen tanto en tu teléfono móvil como en tu escritorio.

Si queréis más detalles os aconsejo leer esta entrada del blog en la que ya se habló de esta gran herramienta o ver u oir el siguiente podcast que realizamos la gente de KDE España.


A longstanding complaint about KDE Plasma is that it’s a pain in the butt to stream videos that are located on Samba shares. It’s a usability issue for sure. I’d like to talk a bit about the origins of the problem and how I helped drive a solution.


For KDE Plasma and apps, the KIO framework is responsible for file access and I/O–including files on Samba shares. Software that uses KIO gets this for free; for other software, KIO can either download the file locally before giving it to the program, or else give the program a Samba URL (e.g. smb://share/path/to/file.avi) and let the program figure out what to do.

KDE does have a KIO-aware video player that could do the job: DragonPlayer. Unfortunately, it’s not actively developed, and a bug prevents this from working.

That leaves 3rd party software, like VLC and MPV. These two don’t use KIO, but they do have Samba clients built in, so they’re able to handle the Samba URLs that KIO gives them!

The problem

…Unless the share is password-protected. In this case, the password must be added to the URL, like this: smb://user:password@share/path/to/file.avi. KIO won’t do that because tossing around user passwords in plaintext is an obvious security problem. So it’s up to the video players to either ask the user for the password to the Samba share, or look it up in the user’s KWallet.

The solution

Ideally, KIO would mount remote locations like Samba shares to a local path using FUSE, and then provide that path to non-KDE apps, which is what GNOME’s GVFs does (and why it works without drama in most GTK-based desktop environments). This would let any video player work with with no modifications, but that’s a task I’m not qualified to tackle, so I decided to attack the problem from another angle: make the most popular video players integrate with KWallet so they can prompt for the password and store it in the user’s wallet.

Unfortunately (but understandably), the MPV developers denied the request. But the VLC developers didn’t, and actually implemented KWallet support in VLC 3.0! But when I tested it using nightly builds of VLC 3.0, I found that it didn’t work, and had even regressed from version 2.

Apparently I was the first person to test the feature in VLC 3.0 beta builds. The VLC developers were a joy to work with, and soon enough, both issues were resolved! I re-tested with later builds and verified the fixes.

Behold, the power of QA!

Once VLC 3.0 is out, KDE Plasma users should be able to play videos located on Samba shares accessed with Dolphin. The first time you do it, VLC will ask you for the Samba share’s password:

After that, VLC will look up the password in your KWallet and you’ll never need to think about it ever again.

Lessons learned

QA is important. If people don’t test features, apps could ship broken.

Users like us are the QA. Most Linux software is not developed and sold commercially, and even distros with commercial backing do not have the resources to test most pre-release software. If we don’t test beta versions of our favorite software, we’ll end up doing it after the release once users are disappointed by bugs and broken features.

The easier you make it to test pre-release builds, the more people will do it and the better your volunteer QA will be. All of this was made possible because the VLC developers provide an Ubuntu PPA with nightly builds, so testing pre-release versions was easy and painless. This is great for Ubuntu users like me, but what about users of Debian, Arch, openSUSE, Fedora, or distros based on them? Had I been one of those users, I probably would have given up on doing this kind of testing.

This is why our work in Discover to make it easy to switch app versions is so important for the future. When every app has beta builds available with only a few clicks in a centralized location with a consistent interface, any user can easily become a beta tester.

Like what you see? Please consider testing beta builds of your favorite software and filing high-quality bugs if you find any issues–even ones that seem so obvious that you can’t imagine that the developers could have missed them. They might only be obvious on your hardware or with your use case! We may not pay for most of our software with money, but that just means developers need our time instead. The price of freedom is eternal QA.

Here’s a list of KDE-related stuff (mostly official FreeBSD ports) the KDE-FreeBSD team handled recently. You could call it “a week in the life of some packagers”, packagers who are also otherwise busy with $work-work.

  • Updated otter-browser (a Qt webengine-based browser) to latest version 0.9.94
  • Added a GTK QPA
  • Updated latte-dock to latest released version 0.7.3
  • Clang6 fixes to older KDE and Qt software (out favorite #define nullptr NULL)
  • Reworked packaging of Qt 5.9 to fix a broken (generated) qconfig.h

And in area51, the unofficial ports tree where we do preparatory work (use the branch kde5-import, which supercedes the plasma5 branch; this one contains the current plan for adding Plasma5 to the ports tree and updating all the KDE Applications), we’ve also got:

  • Updated digikam to 5.8
  • Updated KDE Frameworks to 5.42 (this is waiting on an exp-run to move to official ports)
  • Improved powerdevil backend, thanks to Henry Hu
  • Added plasma5-browser-integration
  • Support Qt4 on aarch64, thanks to Fedora

As usual: you can run a full modern KDE desktop system with Plasma 5 and KDE Applications, from the area51 repository, from the kde5-import branch; official ports have the latest Qt and KDE Frameworks, but not the desktop.

January 16, 2018

As you probably know by now, I have been involved in the Civil Infrastructure Project (CIP), a Linux Foundation Initiative formed in 2016, representing Codethink, a founder Member and coordinating the engineering work in two areas within the project:

  • CIP Kernel maintenance
  • Testing strategy and kernel testing tooling.

In the first front, Ben Hutchings, the Debian Kernel maintainer, a colleague at Codehtink, has been labelled as CIP Kernel maintainer until August 2018. Ben has released in December the latest version of the CIP Kernel 4.4.105-cip15 Currently he is working on releasing a new version, including fixes for Meltdown.CIP Initiative logo

During 2017 until a little after ELCE, I have worked on defining the testing strategy for the CIP kernel and coordinating the efforts towards creating a tool to test it, based on kernelci.org. Robert Marshall has been leading the technical efforts the last few months. The tools was finally called Board at Desk (B@D). Some days before ELCE 2017 CIP released first version of the tool, which is nothing but an integration in a VM of the kernelci.org infrastructure that allow testers to test kernels locally in a board connected directly to their machines. There is no need for a remote centralised infrastructure to collect, process and visualise the results. You can read more about it in the B@D 1.0 Release announcement.

A lot of the work my colleagues and I did for CIP got its visualization at the Embedded Linux Conference Europe 2017, that took place in Prague during the third week of October. A couple of articles summarise the activity:

Codethink’s involvement the last few weeks of 2017 and the beginning of 2018 is reduced to the CIP kernel maintenance so in parallel, I have also reduced my involvement to focus more in customer’s work. I plan to attend to the Open Source Summit Japan 2018 to support again CIP activities.

If you are interested in following the work the CIP is doing to bring Linux based systems to Industrial Grade products, I recommend you join the cip-dev mailing list. You can read a previous post I wrote about my CIP related activity.

Yesterday the KDE Community released the Beta for Plasma 5.12 LTS. With that release the feature freeze for 5.12 is in place and also an eternal feature freeze for KWin/X11. To quote the release announcement: “5.12 is the last release which sees feature development in KWin on X11. With 5.13 onwards only new features relevant to Wayland are going to be added.” This raised quite some questions, concerns and misunderstandings in the social networks. With this blog post I try to address those question and explain why this change in policy is done.

Is KWin/X11 still maintained?

Yes! We are just in the process of releasing an LTS. Of course KWin is fully maintained in the LTS life time. While in 5.8 only X11 was maintained, now we are able to offer maintenance for both X11 and Wayland. For the maintenance we do not differentiate between windowing systems.

Will X11 bugs still be fixed?

As X11 is under maintenance, I expect bugs to still get fixed.

Does this mean that in 5.13 X11 will be unmaintained?

We are going to forward port bug fixes from the 5.12 branch to master. Thus any release after 5.12 will get all bug fixes from 5.12. Given that I would say 5.13 will also be maintained on X11.

Does this mean that in the next LTS X11 will be unmaintained?

We will decide when the time comes. Currently I do not expect that we would drop maintenance.

Does this mean Plasma 5.13 will default to Wayland?

This is about feature freeze for X11. Whether Wayland will be the default or not is completely unrelated to this.

Will X11 users not get any new features in KWin?

Of course there will be new features! Most functionality in KWin is independent of the windowing system. Any improvement to those areas benefit Wayland and X11 users. Currently we have a few improvements in the pipeline, for example tooltips on decoration buttons, improved blur effect, a rework of slide desktop effect, improvements to the cube effect and a few more. All of them will be available to both X11 and Wayland users.

How do you decide whether it’s an X11 only feature?

In the case of KWin this is very simple. There are areas in our code structure which are only get pulled in if run on X11, other areas are marked in an if (x11) section. If the new feature touches this code, it’s probably not going to be added.

Does this feature freeze also apply to other KDE software?

No, but personally I would recommend any maintainer to apply a similar feature freeze. I personally will not help developing any X11 specific feature any more and resigned as maintainer of various X11 specific frameworks this week.

What are you going to do if someone present a feature for X11?

It won’t be merged.

But why?

This requires a little bit more explanation. I had a look at the most prominent issues we had over the last years. Where are our stability problems, where are our quality problems, what costs most development time? I observed that it was always in new features specific to X11. Very often even for features we added to Wayland without causing problems.

So I started to look into why that’s so. The obvious answer that we don’t get bugs for Wayland because nobody uses is, is not the case. We get many bug reports for Wayland and many users are nowadays running Wayland. So the reason must be somewhere else.

On Wayland we are able to test the code. Let’s take an example: we get input events through libinput. For this we have unit tests through mocking. Thus we can automate the testing of the lowest layer. From libinput events are sent into KWin core through an internal API and that we can also use in the integration tests. So we can simulate everything from the point where libinput events would hit KWin core. We can test this properly, we know that we get all events (because KWin is the display manager) and we can test every aspect. We can lock the screen and verify how it works, we can make applications grab the pointer or keyboard and test this. We can invoke global shortcuts, etc. etc. It’s all just as if we get the events through libinput. The quality of these new areas in KWin feels really good.

A few weeks ago some commits I did hit the Linux media about KWin/Wayland without X11 starting too fast and due to that causing bugs. These issues were found through our test suite, before any user would ever be exposed to them.

What we did in the past was taking these new features and bring them to X11. But there we cannot test. There is no way on X11 to e.g. fake a touch screen. On X11 we cannot test how this behaves if we lock the screen or used Alt+Tab. We can write the code and manually test it. Hey it works, awesome! But that was mostly not the case. There were corner cases which caused trouble. And to this comes that the main devs run Wayland instead of X11. If features break they are not exposed to the bugs.

Could you give some examples of things that broke?

Sure! The first feature we backported to X11 was “modifier only shortcut”. We spent months fixing the fallout because of X11 weirdness. Another feature backported was panels on shared screen edges. It worked great for Wayland, but on X11 some corner cases were overseen and caused issues, which affected our users and required time to fix. We backported the touch screen swipe gesture on X11 which was a mess. On X11 touch screens are also mouse events, that made it difficult and created many corner cases.

The problem is not adding the feature. The problem is fixing the bugs created by the new features.

But if a new foo requires adjustments?

KWin won’t be adjusted to any new requirements in the XServer, Mesa, input stack, proprietary drivers, etc. If something breaks it’s the fault of those components which broke it.

Si la última entrada de la categoría de diseño del 2017 fueron dedicados a los cursores, quiero iniciar este año quiero iniciarlo con ellos. Así que bienvenidos a la entrada dedicada a los cursores MacOS Captaine para Plasma 5, para aquellos que quieren dar un toque de la compañía Apple a su dispositivo.

Cursores MacOS Captaine para Plasma 5

Nacidos de la mano y de la mente de Krouke os presento MacOS Captaine, un tema de cursores para Plasma 5 completo y precioso, ideal para tener alternativas al gran tema Brisa de la gente de KDE.

En realidad, este tema de cursores está inspirado en el tema de los macOS pero está basado en KDE Breeze, con lo cual su integración con el escritorio Plasma está más que garantizada.

Cursores MacOS Captaine para Plasma 5

Y como siempre digo, si os gusta este conjunto de cursores podéis “pagarlo” de muchas formas en la página de KDE Store, que estoy seguro que el desarrollador lo agradecerá: puntúale positivamente, hazle un comentario en la página o realiza una donación. Ayudar al desarrollo del Software Libre también se hace simplemente dando las gracias, ayuda mucho más de lo que os podéis imaginar, recordad la campaña I love Free Software Day 2017 de la Free Software Foundation donde se nos recordaba esta forma tan secilla de colaborar con el gran proyecto del Software Libre y que en el blog dedicamos un artículo.

Más información: KDE Store

Cómo cambiar el tema de los cursores en Plasma

Al igual que con los iconos hay varias formas de cambiar el tema de cursores en Plasma, pero la más fácil es:

  • Abrir las Preferencias del Sistema
  • Ir a la sección Temas para el espacio de trabajo
  • Ir a la subsección Tema de Cursor.
  • En esta ventana pinchar en “Obtener nuevos temas”
  • Buscar MacOS Captaine 5 y dar a instalar.
  • Seleccionar el tema y aplicar.


Adventurous users, testers and developers running Artful 17.10 or our development release Bionic 18.04 can now test the beta version of Plasma 5.12 LTS.

An upgrade to the required Frameworks 5.42 is also provided.

As with previous betas, this is experimental and is only suggested for people who are prepared for possible bugs and breakages.

In addition, please be prepared to use ppa-purge to revert changes, should the need arise at some point.

Read more about the beta release at: https://www.kde.org/announcements/plasma-5.11.95.php

If you want to test then:

sudo add-apt-repository ppa:kubuntu-ppa/beta

and then update packages with

sudo apt update
sudo apt full-upgrade

A Wayland session can be made available at the SDDM login screen by installing the package plasma-workspace-wayland. Please note the information on Wayland sessions in the KDE announcement.

Note: Due to Launchpad builder downtime and maintenance due to Meltdown/Spectre fixes, limiting us to amd64/i386 architectures, these builds may be superseded with a rebuild once the builders are back to normal availability.

The primary purpose of this PPA is to assist testing for bugs and quality of the upcoming final Plasma 5.12 LTS release, due for release by KDE on 6th Febuary.

It is anticipated that Kubuntu Bionic Beaver 18.04 LTS will ship with Plasma 5.12.4, the latest point release of 5.12 LTS available at release date.

Bug reports on the beta itself should be reported to bugs.kde.org.

Packaging bugs can be reported as normal to: Kubuntu PPA bugs: https://bugs.launchpad.net/kubuntu-ppa

Should any issues occur, please provide feedback on our mailing lists [1] or IRC [2]

1. Kubuntu-devel mailing list: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
2. Kubuntu IRC channels: #kubuntu & #kubuntu-devel on irc.freenode.net

I guess I’m becoming a Discover developer, since it’s where I seem to spend most of my time these days. It’s just so darn fun since the lead Developer Aleix Pol is super easy to work with, there’s a lot of low-hanging fruit, and with Kirigami, it’s very simple to make consequential changes even when you’re a novice programmer and not very familiar with the codebase. That said, Aleix is still making about 99% of the code changes, and I’m mostly doing UI tweaks, bug screening, promotion, strategy, and work with apps to get their houses in order.

Anyway, here are the user-facing highlights of what we’ve done in the last week or so. There was a lot of work on Snap and Flatpak in particular.

  • Snaps now show their size correctly once installed (KDE bug 389024)
  • During installation of Snaps, the Install button changes so you can’t click it multiple times (KDE bug 388916)
  • Discover now shows the license for Snaps (KDE bug 388735)
  • Discover now shows the size for Snaps that aren’t installed (KDE bug 388734)
  • Discover no longer shows duplicate information in package changelogs for Debian-based distros (KDE bug 387041)
  • Discover now shows the version number for Flatpak apps that define information in their AppStream files (KDE Bug 388968)
  • Discover’s Home page now communicates that it’s a list of featured apps (KDE Phabricator revision D9868)
  • Discover now correctly removes the Tasks entry for an app if you cancel the installation (KDE bug 388915)

Let me share a video that shows a lot of the highlights:

We’ve got Kdenlive available from three sources. Version 17.08.3 is available from a distro, and version 17.12.1 is available straight from the developers via Flatpak. You can also get bleeding-edge development builds if you’d like to follow or participate in the development, or verify that a bug is fixed before the next release. You can install the one that suits you best, and change your selection as your needs and preferences evolve over time. It’s your choice.

You’re looking at the future of software delivery, folks.

Do you want to help make this happen? Instead of my usual spiel about becoming a KDE contributor or donating, consider helping app developers correct and expand their AppStream metadata. The video you just saw isn’t possible without it. Let’s go build the future.

Please read Part 1 of this Blog series about sharing Files on Android and iOS where I wrote about my experiences how to share Files or Content from your Qt App with native Android or iOS Apps.

In the meantime I did some UI tuning and added more info to make it easier to understand and to manage some more use-cases, so expect some more parts of this series next weeks.

Also I found out that not all Android Apps are good citizens of ACTION_EDIT – Intents with ResultCode. After editing and save per ex. Google Fotos sends correct RESULT_OK where other Apps are giving you RESULT_CANCEL. For our workflows it‘s important to know if a File was modified, so as a workaround I store the last-modified-Timestamp before starting the Intent and compare with current Timestamp when Result was handled. All of this is done under the hood and you‘re always getting the correct result code back from EDIT Action.

Some preliminary notes

  • Try it out: all sources are available at GitHub
  • Permissions not checked in Example App: enable WRITE_EXTERNAL_STORAGE manually
  • Current release is for Target SDK 23 ! (Android 7 requires FileProvider – will add later)
  • All Use-Cases are implemented to be used x-platform – currently Android and iOS

If you‘re looking for an Android-only solution please also take a look at AndroidNative project.

Android / iOS

First part covers sharing Files from your App with other Apps on Android and iOS.

This Blog Post is about sharing Files with your Qt App on Android (iOS will follow soon):

  • Use your App as Share Target to receive Content or Files from other Android Apps
  • Impacts on „Sharing Files from your App with other Apps“ (see Part 1)

Intent Filter

To tell the Android OS what kind of Files our App can handle we must add an Intent Filter to AndroidManifest.xml:

<activity … >
        <!-- Handle shared incoming urls -->
            <action android:name="android.intent.action.SEND"/>
            <category android:name="android.intent.category.DEFAULT"/>
            <data android:mimeType="*/*"/>
            <action android:name="android.intent.action.VIEW"/>
            <category android:name="android.intent.category.DEFAULT"/>
            <data android:mimeType="*/*"/>
            <data android:scheme="file"/>
            <data android:scheme="content"/>

Now the App can receive Intents for all kind of MimeType using ACTION_VIEW or ACTION_SEND.

Custom Android Activity

To be able to get the Intent we must add some code to our main Activity, so extend the default QtActivity. To do so create a QShareActivity.java at this location:


public class QShareActivity extends QtActivity
    public void onCreate(Bundle savedInstanceState) {

As next change the Name in AndroidManifest.xml:

<activity ... android:name="org.ekkescorner.examples.sharex.QShareActivity" ...>

Get the incoming Intent

Now the interesting part:
Our App can be opened by other Apps – how do we get the Intent data and read or copy the ‚foreign‘ File ?

This depends from current ApplicationState:
if the App is already running, Android OS will call onNewIntent() – if not our App will be launched and the Intent comes in from onCreate(). The best way is to check the Intent from both methods and then call another method to process the Intent.

Attention: there are some traps to watch !

To inform the UI about an incoming File as usual we want to use a SIGNAL.

If the App is already running we want to open our App exactly on the current Page. Imagine a DropBox-like App where you navigate deep into your File hierarchy and now you want to upload a new Presentation File into the current Folder, but you must edit the Presentation before. So you open PowerPoint or something else, create/edit the presentation and then want to share that File with your App. Of course the User wants to be exactly where he was before without the need to do deep File navigation again.

If our App will be launched by the incoming Intent, onCreate() was called from Android OS to deliver the Intent. Unfortunately at this moment the Qt App isn‘t ready and the SIGNAL will be lost. To avoid this don‘t process the Intent from onCreate() but remember that there‘s a pending Intent.

Later when the Qt App is ready check for pending Intents. HowTo know if the App is ready to process Intents ?

In our Example App we‘re checking the ApplicationState and first time the State becomes Active we ask for pending Intents.

In a real-life business App probably you must at first Login to your Server or get some data from Server, so you‘ll do the check for pending Intents later.

LaunchMode ‚singleInstance‘ vs ‚singleTask‘

As next I found out that the last opened Page wasn‘t shown – instead a white Screen comes up and an error was logged: ‚Surface1 null‘.

Reason was the Launch Mode. Most Android Intent examples are using ‚singleTask‘ so I also did it. Changing the LaunchMode to ‚singleInstance‘ in combination with ‚taskAffinity‘ works better for Qt Apps: now the App opens correct the last opened Page.

Here are the changes to AndroidManifest.xml:

<activity ... android:launchMode="singleInstance" android:taskAffinity="">

Some code snippets:


public class QShareActivity extends QtActivity
    public static boolean isIntentPending;
    public static boolean isInitialized;
    public static String workingDirPath;

    public void onCreate(Bundle savedInstanceState) {
          // now we're checking if the App was started from another Android App via Intent
          Intent theIntent = getIntent();
          if (theIntent != null){
              String theAction = theIntent.getAction();
              if (theAction != null){
                  // delay processIntent();
                  isIntentPending = true;
    // if we are opened from other apps:
    public void onNewIntent(Intent intent) {
      // Intent will be processed, if all is initialized and Qt / QML can handle the event
      if(isInitialized) {
      } else {
          isIntentPending = true;
    public void checkPendingIntents(String workingDir) {
        isInitialized = true;
        workingDirPath = workingDir;
        if(isIntentPending) {
            isIntentPending = false;
    // process the Intent if Action is SEND or VIEW
    private void processIntent(){
      Intent intent = getIntent();
      // do something with the Intent

Check ApplicationState in ApplicationUI.cpp:

#if defined(Q_OS_ANDROID)
void ApplicationUI::onApplicationStateChanged(Qt::ApplicationState applicationState)
    if(applicationState == Qt::ApplicationState::ApplicationActive) {
        // if App was launched from VIEW or SEND Intent
        // there's a race collision: the event will be lost,
        // because App and UI wasn't completely initialized
        // workaround: QShareActivity remembers that an Intent is pending
        if(!mPendingIntentsChecked) {
            mPendingIntentsChecked = true;

Process the incoming Intent

Now let‘s take a look at processIntent() from QShareActivity.java to see how to read the File from the other Android App.

We‘re listening for VIEW and SEND Intent Actions. The ways to get the Uri are different:

Uri intentUri;
String intentScheme;
String intentAction;
if (intent.getAction().equals("android.intent.action.VIEW")){
       intentAction = "VIEW";
       intentUri = intent.getData();
} else if (intent.getAction().equals("android.intent.action.SEND")){
       intentAction = "SEND";
        Bundle bundle = intent.getExtras();
        intentUri = (Uri)bundle.get(Intent.EXTRA_STREAM);
} else {

As next we must check the Scheme to know if it‘s a ‚file‘ or ‚content‘ Scheme.

// content or file
intentScheme = intentUri.getScheme();
if (intentScheme == null){
      // URI as encoded string
      // we are done Qt can deal with file scheme

To get the real FilePath from a Content Uri isn‘t so easy. Found many complicated examples and finally I got a great solution to extract the absolute FilePath from the Content Uri ��

Please take a look at QSharePathResolver.java:


public class QSharePathResolver {
    public static String getRealPathFromURI(final Context context, final Uri uri) {
		// ...

QSharePathResolver.java checks if the content Uri comes from

  • ExternalStorageProvider
  • DownloadsProvider
  • MediaProvider: Images, Video, Audio
  • GoogleFotosUri

and tries to calculate the real path. Now it‘s easy to get the File from an Intent providing a Content Uri:

filePath = QSharePathResolver.getRealPathFromURI(this, intentUri);
// we are done Qt can deal with file scheme

If the Uri couldn‘t be resolved from QSharePathResolver.java we try to read the InputStream. Please take a look at QShareUtils.java: createFile(ContentResolver cR, Uri uri, String fileLocation)

filePath = QShareUtils.createFile(cR, intentUri, workingDirPath);


Ok – we received the File from our custom Activity – how can we provide this to our QML UI where we‘re waiting for a SIGNAL from C++ ?

From Java (Activity) to C++ to emit the SIGNAL for QML

The methods setFileUrlReceived() and setFileReceivedAndSaved() are native methods:

public class QShareActivity extends QtActivity
    // 'file' scheme or resolved from 'content' scheme:
    public static native void setFileUrlReceived(String url);
    // InputStream from 'content' scheme:
    public static native void setFileReceivedAndSaved(String url);

Native Methods are implemented in C++ via JNICALL – see all details in AndroidShareUtils.cpp:

#ifdef __cplusplus
extern "C" {
  Java_org_ekkescorner_examples_sharex_QShareActivity_setFileUrlReceived(JNIEnv *env,
                                        jobject obj,
                                        jstring url)
    const char *urlStr = env->GetStringUTFChars(url, NULL);
    Q_UNUSED (obj)
    env->ReleaseStringUTFChars(url, urlStr);
  Java_org_ekkescorner_examples_sharex_QShareActivity_setFileReceivedAndSaved(JNIEnv *env,
                                        jobject obj,
                                        jstring url)
    const char *urlStr = env->GetStringUTFChars(url, NULL);
    Q_UNUSED (obj)
    env->ReleaseStringUTFChars(url, urlStr);
#ifdef __cplusplus

If you want to learn more about JNICALL and other ways to manage them, here‘s a great Blog Post from BogDan Vatra : qt-android-episode-5.

JNICALL is like a bridge from Java to C++:

void AndroidShareUtils::setFileUrlReceived(const QString &url)
    QString myUrl;
    if(url.startsWith("file://")) {
        myUrl= url.right(url.length()-7);
    } else {
        myUrl= url;
    // check if File exists
    QFileInfo fileInfo = QFileInfo(myUrl);
    if(fileInfo.exists()) {
        emit fileUrlReceived(myUrl);
    } else {
        emit shareError(0, tr("File does not exist: %1").arg(myUrl));

This JNICALL enables us to emit the SIGNAL that we received an Intent from another Android App providing access to a File.


Test it !

Now it‘s a good point to test it. Open Google Photos, select an Image and ShareWith shows ‚ekkes SHARE Example‘ App as target:


Select ‚ekkes SHARE Example‘ and Android will open our App. If the App already was opened, the current Page will be displayed and include the Image:


onActivityResult() (JAVA) vs QAndroidActivityResultReceiver (JNI)

While writing Part 1 of this Blog series I didn‘t found a way to get the Result back if Intent was started with Result from QShareUtils.java (Workflow ‚A‘ – the JAVA way)

QtNative.activity().startActivityForResult(Intent.createChooser(viewIntent, title), requestId);

@hamalaiv comment pointed me to the right direction: to get the Result back a Custom Activity must be used.

Ok – we‘re now using a custom Activity (QShareActivity.java) – let‘s test it.

To get the Result back, we must be implemented this JAVA code:

public class QShareActivity extends QtActivity
    public static native void fireActivityResult(int requestCode, int resultCode);

    protected void onActivityResult(int requestCode, int resultCode, Intent data) {
        fireActivityResult(requestCode, resultCode);

and this C / C++ Code:

  Java_org_ekkescorner_examples_sharex_QShareActivity_fireActivityResult(JNIEnv *env,
                                        jobject obj,
                                        jint requestCode,
                                        jint resultCode)
    Q_UNUSED (obj)
    Q_UNUSED (env)
    AndroidShareUtils::getInstance()->onActivityResult(requestCode, resultCode);
void AndroidShareUtils::onActivityResult(int requestCode, int resultCode)
    processActivityResult(requestCode, resultCode);
void AndroidShareUtils::processActivityResult(int requestCode, int resultCode)
    if(resultCode == RESULT_OK) {
        emit shareEditDone(requestCode);
    } else if(resultCode == RESULT_CANCELED) {
		if(mIsEditMode) {
			// check Timestamp and
			emit shareEditDone(requestCode);
			// or
			emit shareFinished(requestCode);
        emit shareFinished(requestCode);
    } else {
        emit shareError(requestCode, tr("Share: an Error occured"));


Testing the JAVA way sharing Files with other Android Apps now works as expected with or without ResultCode. I removed the workaround code from ApplicationUI.

But there‘s a Drawback: Testing the JNI way (Part 1, Workflow ‚B‘) using QAndroidActivityResultReceiver only works without ResultCode. If starting the Intent with ResultCode

QtAndroid::startActivity(jniIntent, requestId, this);

the QAndroidActivityResultReceiver wasn‘t called for the Result: instead the Result comes back via our custom Activity onActivityResult() method using a wrong RequestId.

Lesson learned: never use QAndroidActivityResultReceiver (C++, JNI) and onActivityResult() (JAVA Activity) together in one App.

To test this please comment or rename onActivityResult() and you‘ll see the JNI implementation alone works well.

There‘s another problem if we want to share one of our Files with other Apps, because now we‘re source and also target for same MimeTypes. This means: our own App will be listed as a target:


Tried some ways to workaround, but doesn‘t work well and selecting the own App as Target with Result crashed the App because there was a collision with LaunchMode ‚singleInstance‘.

Unfortunately there‘s no way to exclude targets using Intent Filter. So we have to create a custom Chooser without listing our own App as Target. Thanks to this thread at StackOverFlow I found a way to solve this. Please take a look at QShareUtils.java

public static boolean createCustomChooserAndStartActivity(Intent theIntent, String title, int requestId) {
	// ...

Here‘s a short summary:

  • Create Intent as before and use as template
  • Context is QtNative.activity()
  • Get packageManager from context.getPackageManager()
  • Retrieve all Apps (List) for Template – Intent: packageManager.queryIntentActivities()
  • Sort Apps (List) by Label
  • From Apps (List) create List
    • Create Intent as Copy from Template – Intent
    • Add setPackage(targetPackageName)
    • Don‘t add Intent to list if Target PackageName equals own PackageName
    • If needed also watch a Blacklist

We created a List of Intents, where all Intents are based on our previously created Template – Intent with an extra PackageName added. This means each Intent will only detect one specific App as Target.

Now the tricky part:

We want to all collected Intents as EXTRA_INITIAL_INTENTS and we‘re using the last one from list of Intents as initializing Intent because the Chooser adds its initializing Intent to the end of EXTRA_INITIAL_INTENTS ��

Intent chooserIntent = Intent.createChooser(targetedIntents.remove(targetedIntents.size() - 1), title);
if (targetedIntents.isEmpty()) {
    Log.d("ekkescorner", title+" only one Intent left for Chooser");
} else {
    chooserIntent.putExtra(Intent.EXTRA_INITIAL_INTENTS, targetedIntents.toArray(new Parcelable[] {}));

QtNative.activity().startActivityForResult(chooserIntent, requestId);


Now it works as expected: our own App doesn‘t appear in list of target Apps.

Attention: onActivityResult() (JAVA) sometimes is too fast compared with QAndroidActivityResultReceiver (JNI)

While testing Action SEND I noticed that Files are not copied to other Apps or not printed, because ‚File does not exist‘. This happens only if going the JAVA way getting the Result back from onActivityResult(), but not if using JNI and QAndroidActivityResultReceiver.
When getting the Result back I‘m deleting the File from Documents Folder (see Part1) and it seems that onActivityResult() sends the Result before File was fully copied / printed.
As workaround I added a Timer with 500ms delay in QML before deleting the File.

From now on I‘ll use the JAVA way (Workflow ‚A‘ in Overview) as default to share Files with other Apps, because it‘s much easier to implement specific behaviour (as our Chooser Intent) using JAVA instead of JNI. The pure JNI way still remains in the code to get a feeling HowTo solve it without JAVA code.

Share from other iOS Apps with our Qt App

As next I want to implement the same functionality for iOS – so stay tuned for Part 3.

My goal is always to provide easy-to-use x-platform solutions for Android and iOS. That‘s why I‘m using Qt ��

Some years ago I developed mobile business Apps for BlackBerry10 (BB10) where the InvocationFramework makes it easy to share content or files between Apps.

BB10 Customers are now (and next years) in transition from BB10 to Android, iOS or both and of course I want to motivate them to use Qt as their new Framework. Last two years I implemented most of my patterns using Qt and QtQuickControls2 for Android and iOS. Having features only for one platform is like having no solution. Step-by-step I‘m reaching feature-parity with BB10.

I‘m also blogging about all of this to make it easy for mobile devs to start with Qt.

Back to Sharing Example.

Need Help – offer Bonus

As I understand it right, iOS Extensions should be used to share Files or Content from other iOS Apps to our Qt App and it seems that this isn‘t supported yet our of the box from QtCreator. If there are some manual steps needed I need a description HowTo do this.

Remember: I‘m a mobile Business App Developer, not a Xcode expert and not an Obj-C expert and I‘m doing all my work from QtCreator – not commandline.

I‘m open for all tips and any help HowTo …

  • Open Qt App from other iOS Apps sharing Text Content or Files
  • Reopen Qt App from other iOS Apps at current Page if Qt App is already running
  • Emit SIGNAL about received Files or Text and copy Files into AppData location
  • Development workflow to solve this from QtCreator / Xcode

Bonus: If someone can provide a small sample project before I found out all the steps and blogged about, the first one will get a Bonus of 500 € from me. Please be aware that I‘ll modify and include code into my Share Example as Open Source code.

Have Fun

Now it‘s time to download current Version from Github, build and run the Sharing Example App.

The post Sharing Files on Android or iOS from or with your Qt App – Part 2 appeared first on Qt Blog.

Despite the security meltdown that swept over the tech community, our 2018 started out great - and it's all thanks to you. Your donations helped us reach the goal of our end-of-year fundraiser.

We would like to thank everyone who participated in the fundraiser, and also to all our community members who spread the word about it on social media and their blogs. You are all a wonderful community, and we are proud to be a part of this journey with you.

With our funds recharged and our hearts full of gratitude, we are ready to take on the new year and all the challenges it brings. The work is already in full swing - we released a bugfix update for KDE Applications and a new version of KDE Frameworks. But what else is there to look forward to in 2018? Read on to find out.

Plasma 5.12 Puts the "S" in Speed (and Stability)

Having released an update for Plasma 5.11 just at the beginning of 2018, Plasma developers are now gearing up for the first major release of the year. Plasma 5.12 will be the new LTS (Long-Term Support) version, replacing Plasma 5.8.

Discover, now with better application screenshots.

Since many Linux distributions will rely on this version of Plasma, the developers wanted to make it as stable and fast as possible. Startup speed and memory usage will be visibly improved, particularly on low-end devices.

The KScreen utility will allow Wayland users to adjust the output resolution as well as enable and disable selected outputs. Discover, the software management application, will support the dist-upgrade command for new major releases of distributions. Application screenshots will look better than ever, and support some useful options such as navigation between images. A lot of work has been done on Flatpak support in Discover, and plenty of critical, usability-impeding bugs have been fixed.

It is important to note that new features for KWin on X11 will no longer be developed after Plasma 5.12. Moving forward, only the features relevant to Wayland will be added.

Krita Paints Masterpiece Features

Krita 4.0 is almost here!

Digital artists, rejoice! A major Krita release with big, beautiful changes is coming this year. With Krita 3.3.3 released just recently, all the attention is now shifting towards Krita 4.0. This version will bring improved integration with Inkscape, allowing the users to copy and paste shapes directly between the two applications.

Krita 4.0 supports Python scripting, comes with a new text tool, and allows bigger brush sizes. Expect two major changes related to file formats, too - instead of ODG, SVG will be the new default vector format. Additionally, the file format for color palettes will change, and the new one will let users create their own color groups.

If you're feeling brave enough, you can already try Krita 4.0 Beta today, and don't forget to report bugs if you find any!

New Apps Take the Stage

We're always happy when new or small projects take off and grow to become an important part of the KDE Community. Here's a small selection of some interesting KDE applications to keep an eye on:


If you're into 3D printing, you should try Atelier. Along with its backend, AtCore, Atelier allows you to control your 3D printer, calibrate printer settings, check its status, and send print jobs to the printer. Although the application is still in beta, you can use it on Linux, macOS, and Windows, and there is even an AppImage if you'd prefer not bother with dependencies.

A major redesign of the user interface is in progress, so you can expect better views and multiple workspaces that will allow you to manage more than one 3D printer using one instance of Atelier.


With Zanshin, you'll never forget to buy those kiwis.

Productivity isn't such a hot buzzword anymore, but people are still looking for better ways to organize their tasks. Enter Zanshin, a small but powerful app grounded in the philosophy of simplicity. It allows you to sort your tasks into projects and divide them into different contexts.

Zanshin integrates with the KDE PIM suite and KRunner, making it easy to add new tasks from incoming email or display them in your calendar. A new version of Zanshin just came out, with features such as recurrent tasks, support for attachments, and the ability to focus on the currently active task to minimize distraction.

Latte Dock

Latte Dock officially became a KDE project (as part of our Extragear collection) at the end of 2017, but it has been a community favorite for a long time.

This highly configurable dock allows you to organize your launchers and running applications, and new features are added constantly. Recent changes made it possible to share custom dock layouts with other users (and download theirs), and improved dynamic backgrounds for application windows that interact with the dock.


Elisa is simple by default, powerful when needed.

A new music player on the KDE stage, Elisa is still in development, but it's an exciting project to follow. One of its main features is music indexing, which optimizes the speed of your music collection. Elisa allows you to browse music by artist and album, or display all tracks, as well as create custom playlists. The developers are currently focused on improving the interface. You can try Elisa on Linux and Windows.

Akademy on the Blue Danube

August may seem far away, but we're already preparing for the biggest KDE Community event of the year - Akademy 2018! The annual gathering of KDE community members will take place in Vienna, Austria, from the 11th to the 17th of August at the University of Technology (TU Wien).

The call for participation is now open, and you can send your proposals for talks, panels, and workshops until March 12th, 2018. Of course, you can also simply come as an attendee -- after all, there is no admission fee, and everyone is welcome. Whether you're a seasoned KDE contributor or someone who just started using KDE software two days ago, we would like to meet you!

More Ways for You to Contribute

During our end-of-year fundraiser, many people asked us about using cryptocurrency to support KDE. We listened, and we made it possible - now you can donate Bitcoin using bitpay. You can also donate directly from our Facebook page, or participate in our Join the Game project, where you can become a supporting member of KDE and take part in our General Assembly meetings.

Of course, it's not all about the money. If you would like to contribute to KDE as a developer, take a look at our Season of KDE mentorship project. Want to write articles about KDE for this website? Get in touch with the KDE Promo team, and they will help you get started. There are so many venues to becoming a KDE contributor, and as part of our long-term goals, we will work on making the process of joining easier.

Let's konquer 2018 together!

Dot Categories:

For the past year at Blue Systems my colleagues and I have been working on getting Plasma 5 ready for ARMv8 systems such as the Pinebook. If you were at QtCon this year, you might have also seen our awesome team demo’ing these systems at the KDE booth along with Plasma on ARMv7 systems such as the ODROID C1.

A year ago, the state of Plasma on ARMv8 looked somewhat like this bench, covered in snow, not particularly inviting. Things worked, or at least appeared to, only to break as soon as you started digging deeper into the innards of the system. One of the biggest hurdles in the ARM space right now is getting graphics working on a Linux system. Working with the Pine64 and Pinebook was no exception.

While the X11 and DRM stacks are open source, the OpenGLES implementation is only provided as a proprietary blob. Better than nothing, but still not quite up to the quality that we were looking for.

Once we figured out where we could improve things, we started getting our hands dirty and improving things as best as we could and learning more about the graphics stack as a whole. This lead to improvements such as getting a working hwcursor (thanks David!) for the Pinebook, making sure we don’t have garbage on the screen when X11 gets started and a failed attempt to get Debian to rebuild Qt on ARM64 systems with GLES instead of OpenGL ( since there is no OpenGL on the Pinebook ).

We also bench marked important metrics that would affect our users such as time to login manager, time to desktop and the time it took to launch a file manager such as Dolphin. With these metrics in hand, the Plasma team at Blue Systems set out to improve these metrics by improving the various bits and pieces within the KDE product ecosystem. It’s important to note that all of the improvements that have been made will also benefit x86 users, though the impact will really be seen on ARM devices.

The future for Plasma on ARMv8 looks pretty bright from here on out to me. There’s still a lot of work to be done, but we’ve got a pretty good handle on it for now. There were massive improvements once we identified major pain points such as Qt using OpenGL instead of GLES and fixing issues within Qt itself.

I’d also like to take a moment and say a massive thanks to the Pine community as well. They’ve been an amazing group of people to work with. They even released a Wayland driver that could potentially become the building block to deliver a ARMv8 laptop that can run Plasma atop Wayland in the future! Thank you so much, it really is appreciated.

January 15, 2018

Just when I thought to have missed yet another Plasma feature freeze deadline with the one for Plasma 5.12 LTS and thus a good(?) excuse to re-decrease priority of some planned work on the Plasma Addons Weather applet (from the kdeplasma-addons repo, not to be mixed up with clearmartin’s one from github/store.kde.org) once more and thus delay things even further to a day that may never come, the Plasma team found they need to shift the deadline by some weeks to be after the KDE Frameworks 5.42.0 release.
So excuse gone, no other quickly found… time to do a git pull and open the editor.

It’s almost two years ago that the old Plasma Addons Weather applet got ported to Plasma 5 with an initial release in Plasma 5.6. That activity resulted in some plans for further work, which then though met a sad fate of plans… staying on paper to some degree. Let’s revisit the points of the plan and their state:

  • Breeze-style weather state icons: done -> hurra for hard-working Ken
  • Overhaul of look: only cosmetic changes applied, bigger redesign never turned into code -> FAIL
  • support for more weather data providers: a template for provider plugins has been done and added, but no-one ever contributed a plugin for a new provider -> FAIL so far
  • also temperature displayed in compact widget variant, like on panel: got lost in layouting code -> FAIL
  • privacy control which weather data providers are queried on finding weather stations: never worked on -> FAIL

Add to that a Plasma 5 Porting TODO item from the code:

  • Restore night-style icons for observation weather conditions at night: never worked on -> FAIL

Living in some slightly northern of the northern hemisphere, right now the days are short and the temperature is often around the freezing point. Which makes the weather applet look slightly broken and useless: not showing the temperature directly on the panel for a quick glance to check whether it is slippery outside, but showing the weather observation report with the sun symbol in the icon when it is dark outside… who needs or wants that. Still the applet is working too well for just proposing to wipe it from the repos in favour of one of the alternative ones out there. Of course there is also that tiny bit of pride in the porting work done, which begs for throwing more good time after it… ��

So motivation collected, some coding time shuffled free: the fight against the new Plasma 5.12 feature freeze deadline was picked up. And to make the already too long story short, I can now happily report that with the help of Kai Uwe and some further random Plasma developers the last three items can now be checked off as Done starting with Plasma 5.12 ��
(Well, almost, truth is that proper night-style icons are still not available for some stations/providers or delivered data, fixing needs a bigger redesign, which is left for another time)

Selecting which weather service providers to query for a location in the Plasma Weather applet. Spot also the optional temperature shown on both panels next to the weather state icon, as well as proper night-style weather state icon for England’s London during current CET night (sorry for German/English mix in UI, too sleepy for proper setup)

So some 2018 FLOSS contributions of mine done. Now I can slack off the rest of this year! ��
And watch you doing yours by implementing a plugin for your favorite weather data provider?
Which, BTW, will be also useful to any other Plasma applet which makes use of the Plasma Weather dataengine from the plasma-workspace repo.

With all the happiness after being selected for SoK 2018, I was looking forward to start working on my project with whole dedication. My project aims to complete port of a brain-boosting memory activity called “Railroad” (in which kids have to observe the given train and memorize it within given time and then try to rebuild it) from Gtk+ to Qt version. It is a part of project GCompris(a high-quality educational software suite, including a large number of activities for children aged 2 to 10). My mentors are Timothée Giet and Rudra Nil Basu, along with them I’d like to thank a lot to Johnny Jazeix and Divyam Madaan for helping me with my project. My SoK proposal can be found here –> SoK Proposal. And my progress can be tracked at –> Railroad branch.

I started with introducing myself to the GCompris community and discussing my implementation plans with the mentors. My mentors helped me to get my KDE developer account and setup git. First error which I encountered was during git clone, after googling about it and discussing with mentors I got to know that it was due to the firewall(thanks to my college).

My main task for first two weeks was to create a new layout for the activity, make the activity look better in small screen devices and remove horizontal scrolling. This activity was already started during previous SoK, so most of the code was already written. I compiled the activity and started understanding its code, my previous contributions on GCompris helped me to understand the code fastly. Previously it was hard-coded to have a fixed no. of wagons in fixed no. of rows which caused horizontal scrolling. I implemented a GridView based layout which helped to remove the need for horizontal scrolling and made UI look more beautiful.

1. For Horizontal Screens

2. For Vertical Screens

After working on UI, I created five levels based on increasing difficulty and fixed some issues in UI based on reviews from my mentors. Every error opened an opportunity for me to learn something new. I’ll be working on implementing keyboard navigations next week.

Some of the new things which I learned during this project so far
> Importance of Version Control System.
> Quality of code is more important than Quantity of code.
> Dividing a big task into small tasks and then proceeding.
> Using SSH keys.
> An image when opened with a text editor shows real mystery behind it.

In conclusion, SoK proves to be a great experience thus far, being a pleasure to work on a project focused mainly on Education. For further updates, stay tuned!

Seguimos con la cuarta temporada de los vídeo podcast de la Comunidad KDE española. En esta ocasión el tema del próximo podcast será KDE e.V y KDE España.  ¿Te interesa? Pues si nada lo impide, el próximo martes 23 de enero a las 22:00 horas peninsulares (UTC/GMT +1) nos encontremos en directo.

KDE e.V y KDE España protagonistas del nuevo podcast de KDE España

KDE e.V y KDE EspañaEs hora de morarse el ombligo. Tras 24 ediciones de podcast de KDE España es el momento de hablar un poco de uno de las asociaciones que hacen posible que todos los proyectos, programas, iniciativas y eventos de los que hemos ido hablando desde el 2014 ocupen el foco central de nuestro programa mensual.

Así que. si no ocurre algún problema, el próximo martes 23 de enero KDE e.V y KDE España protagonistas del nuevo podcast de KDE España para celebrar los 25 primeros episodios de esta forma de divulgar el proyecto Libre que es KDE.

El primero como fundación internacional que guía el destino del proyecto de la Comunidad y vela por los intereses de la misma.

KDE e.V y KDE EspañaEl segundo porque se encarga de la promoción de este gran proyecto en la lengua de Cervantes y se ha convertido en una organización a tener en cuenta en la difusión del Software Libre.

Así que es os invito a escucharnos (y vernos otra vez) en directo hablar sobre las motivaciones, el trabajo, sus acciones, de la forma de conocer más sobre ellas y cómo hacerse miembro de estas dos organizaciones.

Para poder disfrutar del podcast en directo seguiremos utilizando los servicios de acontecimiento en vivo de Youtube y contestaremos, si podemos, vuestras preguntas en directo.

¡Os esperamos el martes 23 de enero a las 22:00 peninsulares!

Los podcast de KDE España

Ayúdanos a decidir el temaEn un afán de acercarnos más a todos los simpatizantes de KDE hace un tiempo que empezamos a realizar podcast. En ellos varios miembros de la Comunidad KDE de España nos reunimos para hablar un poco de los diversos proyectos.

Hemos hablado de muchos temas como por ejemplo Akademy, KDE Connect, Plasma Mobile, Akademy-es, prvivacidad, KDE Edu, etc.

Podéis seguirnos en el canal de Youtube de KDE España o en Ivoox, donde estamos subiendo poco a poco los audios emitidos. Esperamos que os gusten.

What happens in Discover in when an app is available from multiple sources–say, Flathub as well as your distro’s packages?

As long as both versions of the app provide the same AppStream ID, Discover will show a single entry and let you choose which one you want to install, like this:

But if any of the available versions use a different AppStream ID, they’ll show up separately:

Uuurgh, how awful. Which GIMP is the real GIMP? And why do they all have different names?! Flathub uses org.gimp.GIMP as the AppStream ID, while The GIMP developers provide gimp.desktop for distros to use as the AppStream ID. And the Snap version provides no AppStream ID, sadly.

So we need the GIMP developers to change their AppStream ID to the same one that Flathub uses (which actually follows the AppStream spec). I submitted a patch to fix it that was recently accepted, so this should be resolved with the next GIMP release. That will unify the first two, but the third–which comes from Snap–won’t get rolled up into it until Snap uses AppStream IDs. The Snap folks are on the case, but it’s still a work in progress.

But adopting AppStream only work as long as developers are populating their AppStream files with valid IDs! An AppStream ID is supposed to look like com.myurl.NameOfMyApp, not NameOfMyApp.desktop or com.myurl.NameOfMyApp.desktop. Flathub gets this right, but a lot of app developers themselves get it wrong, and it’s up to us to help them, and make sure the AppStream IDs in their files match those on Flathub.

I’ve started to submit patches for apps that unify their AppStream IDs:

What can I do to help?

See all those patches I submitted? You can do the same! If you use any apps that have AppStream IDs in their distro packaging that are incorrect and different from what’s in Flathub, then submit a patch to fix it! Keep in mind the following guidelines:

  1. Dashes/hyphens must be replaced with underscores: com.shutter-project.shutter is wrong and should be com.shutter_project.shutter
  2. Leading digits in the app name are not allowed: com.wildfiregames.0ad is wrong and should be com.wildfiregames._0ad
  3. If the AppStream ID used for Flathub is wrong, don’t replicate that wrongness with your patches; encourage developers to use correct AppStream IDs and file a bug for the app on Flathub, like this one.

For extra credit, you can also submit patches that add <release> information, too. This will make the app’s version string show up in Discover:

And here’s the properly formatted <release> information in HexChat’s AppStream file that provides it: https://github.com/hexchat/hexchat/blob/master/data/misc/io.github.Hexchat.appdata.xml.in#L29

I know this isn’t the most immediately rewarding work, but it’s super important to make Flatpak (and later Snap) work properly in a mixed environment where you also have distro packages available. If you want the world to be Snappier or more Flatpacked, this is probably the easiest way to make it happen if you’re not a programmer or a packager. If you need a hand, you can email flatpak@lists.freedesktop.org or check out the #flatpak IRC channel on freenode.org.

As always, if you find this work useful or valuable, please consider becoming a KDE contributor or donating to KDE! But do consider submitting patches for Apps that have sparse or incorrect AppStream data. You’ll be doing your part to pull Linux software distribution into the future.release

January 14, 2018

People often ask about the state of Flatpak in Discover, so today I’m going to write about that. Thew good news is that Discover’s Flatpak support is very good and getting better all the time. It’s fully production ready and we encourage you to use it!

To download Flatpak apps in Discover, you need to have the Flatpak backend installed. In many distros, it’s a separate package that doesn’t come installed by default. In Ubuntu-based distros, you can install it by running sudo apt install plasma-discover-flatpak-backend. in Discover 5.12, you’ll even be able to install different backends from within Discover itself, by searching for “Flatpak” or “Snap”. If you want faster Flatpak adoption, please petition your distros to install the Flatpak backend by default!

Once the Flatpak backend is installed, you need to add at least one Flatpak repo. Distros can provision this with default entries, but most don’t. Bug your distro if you want a better experience here! Until then, you can go to Discover’s Settings page and click the “Add Flathub” button to add Flathub as a source. After that, you can access Flatpak apps by browsing or searching through the app lists as normal. You can also go to the settings page and click on the Flatpak entry, which will show you just the Flatpak apps from that repo:

You can add multiple Flatpak repos; to do so, go to the Settings page, click the Hamburger menu button next to the text “Flatpak”, and click “Add Source…” Then enter the URL of the Flatpak repo you want to add. Discover also handles this properly when you click on a repo URL in your web browser.

Multiple Flatpak repos enable users to effortlessly switch between stable and up-to-date versions of apps, each version provided by a different repo. Right now, we’re generally stuck with one or the other, according to our distro’s packaging policy: Arch and other rolling distros say that you always get the latest version; Debian and Ubuntu and other stable release distros say that you always get a specific version that’s frozen in time. Sometimes that’s not right for you, because maybe the latest version has a bad bug, or an old stable version is missing features you want that were implemented in a later version.

Flatpak liberates us from this. You could add Flathub (https://flathub.org/repo/flathub.flatpakrepo) and also KDE’s nightly testing repo (https://distribute.kde.org/kdeapps.flatpakrepo). Then when you go to install a KDE app that’s present in both, you can choose the source! Maybe you want to live on the bleeding edge, but if you run into an issue, you can easily revert your installation to the stable version. It’s pretty awesome.

If any of this seems cool and useful, please don’t hesitate to join our team or make a donation to KDE. My next post shares some specific things you can do to help push Flatpak adoption, even without being a programmer.

Lac Mirroir, Le Melezet, Ceillac, French Alps

Following the release of 5.7.0 published in September 2017, the digiKam team is proud to announce the new release 5.8.0 of the digiKam Software Collection. In this version a lot of work has happened behind the scenes and in fixing bugs as usual, which does not mean there are no enhancements: a new tool to export collections to UPNP/DLNA compatible devices has been introduced.

Bugs Triage

Following the large update of bug categories processed before the previous release, we have been able to reassign entries to the right components. With the help of pre-release bundles computed each day, we have been able to provide a digiKam test version along with the fixes applied to close reports in bugzilla. The result with this release is a set of more than 200 entries officially closed.

Application Bundle Improvements

MacOS and Windows digiKam Installers in Action

For each platform supported by the digiKam project, we propose a bundle package ready to use, which embed all the needs to have a suitable application. digiKam project confirm the support of The AppImage format as the best Linux bundle, which has been updated to last SDK available in build virtual machine based on Linux Centos. This one now permits to run the bundle under Firejail sandboxing technology for a better security level..

Showfoto Running Under Windows

The Windows installer is now built with the latest NSIS version to be compatible with Windows 10. The installer code has also been cleaned to remove obsolete packaging plugins and to prevent false virus detections while installing. Note that all digiKam Windows bundles are fully built under Linux with the MXE cross-compiler and there is no risk to inject Windows viruses in the application.

Showfoto Running Under MacOS

All bundles, including the MacOS package build with the latest Packages, now include more optional features available on digiKam and also Showfoto, as some new low level libraries have been ported to pure Qt5, such as digital scanner support and events file support with export to Calendar tool.

Mysql Support Improvements

Mysql Config Panel and Migration Tool

A lot of work has been done around the Mysql support with the help of end users testing step by step progress and the relevant fixes applied daily. For these hacking stages, the pre-release bundles have really helped a lot, by providing a ready to use beta version of digiKam including all debug statements necessary to investigate the dysfunctions, especially for the database schema update performed on older collections hosted on a Mysql or Mariadb server. The migration tools have also received many fixes, especially to move from Sqlite databases, when collections grow substantially and over time become more and more slow. Now, the migration tool can import and export better from/to Mysql or Sqlite without data-loss while databases are being converted.

Export to UPNP/DLNA devices

New Tool to Share Collections With DLNA Devices

In September 2017, the digiKam team has been invited to take part in the Randa Meetings. In this tiny town in the Swiss alps a lot of KDE developers work on improving their software. We have focused the reunion on including the new media server dedicated to sharing collection contents on local networks with compatible DLNA devices or applications, such as tablets, cellulars, TV, etc. This tool is now available in all digiKam views through the main Tools menu and also in Showfoto.

Showofoto DLNA Server Visible into VLC

There are plenty of DLNA applications available in digital stores like iTunes or GooglePlay. As the DLNA and UPNP protocols are standardized, we don’t need to develop dedicated applications for each client device that wants to access the digiKam/Showfoto contents.

Port DropBox Export Tools to OAuth2

digiKam DropBox Export Tool Running Under Windows

Concerning digiKam export tools to remote Internet services, the port to OAuth version 2 is advancing steadily with more work planned in the course of the year. After porting the Flickr and Imgur export tools with the 5.7.0 release, the DropBox export tool is now ported to the new authentication API, so after a short time of dysfunction the tool is back and ready for use in production. In the future other tools, such as Facebook and GPhoto export, will be ported to OAuth version 2. This will probably be a subject for the students working with us for the upcoming Google Summer of Code 2018.

Final Words

As always, but especially noteworthy this time, you can look at the list of 231 resolved issues for detailed information.

digiKam 5.8.0 Software collection source code tarball, Linux 32/64 bits AppImage bundles, MacOS package, and Windows 32/64 bits installers can be downloaded from this repository.

Happy new year 2018 and happy digiKaming!

January 12, 2018

Elisa is a music player designed to be simple and nice to use. It allows to browse music by album, artist or all tracks. You can build and play your own playlist. We aim to build a fluid interface that is easy to use.

We are preparing for the next alpha release when the following features will be done. Alexander is working on a metadata view for tracks. I am working on cleaning the different grid views into a generic one.

Diego Gangl did several modifications of the interface as part of the interactions with KDE VDG.

All in all, Elisa now looks like that:

Screenshot_20180112_174013Snapshot of album view including the changed application menu

The following things have been integrated in Elisa git repository:

  • Fix modification of files with DatabaseInterface::modifyTracksList by Matthieu Gallien ;
  • This patch increases the blur in the headerbar background, increases contrast
    between background and text, and brings the labels closer together by Diego Gangl ;
  • Tune appearance of all albums and all artists views by Matthieu Gallien ;
  • Fix wrong id reference in FilterBar by Matthieu Gallien ;
  • In all models, calls base class roleNames before adding new role names by Matthieu Gallien ;
  • Simplify the definition of custom roles in all models by Matthieu Gallien ;
  • Allow MusicArtist to be stored in a QVariant by Matthieu Gallien ;
  • Allow to enqueue artist in MediaPlayList by using MusicArtist objects by Matthieu Gallien ;
  • Change height of delegate in GridView by Matthieu Gallien ;
  • Fix a typo in the imported tracks notification by Diego Gangl ;
  • Make shadows centered and slightly larger. Fits better with other shadows in the
    desktop (like dolphin and widgets), and it also aligns with the new shadows for
    breeze (D9549) by Diego Gangl ;
  • Fixes key arrow navigation in list and gridviews and implements enter and return key actions for delegates by Alexander Stippich ;
  • Allow elisa to open any external files, scan them and enqueue them by Matthieu Gallien ;
  • Syncs the windows theme file with the current main theme file. Removes bundled icons for windows which are not needed as proven by ViewSelector.qml, but also tested on windows by Alexander Stippich ;
  • Make the delegates more appealing when using a dark theme also add hover animations while keeping the loader component by Alexander Stippich ;
  • Fix keyboard navigation for album artist view too by Alexander Stippich ;
  • Move all icon and image definitions to theme file and make some consistency fixes. In anticipation of a colorized version of the artist image, there are two definitions which currently hold the same icon. Also enables the display of a default cover in context view by Alexander Stippich ;
  • qml profiler shows a few percent of cpu time spent just for the creation for simple buttons for the delegates. cut this by loading on demand by Alexander Stippich ;
  • Try to find png files for covers if jpegs do not exist can probably be made a lot smarter than this, but kept it simple for now by Alexander Stippich ;
  • Try to fix build (as seen on binary-factory.kde.org) by Matthieu Gallien ;
  • Re-order menu items to fit better with the order used in other KDE applications by Diego Gangl.


Happy new year every one!

PackageKitQt is a Qt Library to interface with PackageKit

It’s been a while that I don’t do a proper PackageKitQt release, mostly because I’m focusing on other projects, but PackageKit API itself isn’t evolving as fast as it was, so updating stuff is quite easy.

It haven’t seems a proper release in a while, it got several patches from other contributors, including the Qt5 port, so 0.10.0 is for that, the 1.0.0 release is to match PackageKit 1.0.0 API, while 0.10.0 works with that some signals and methods where removed from PackageKit which where useless in PackageKitQt.

Add to 1.0.0 release the complete Offline updates interface some API cleanups, missing enums and a performance improvement on parsing package ids.

Due the complexity and effort used to roll a release, from now on releases will be done with tags on GitHub, so packagers stays tuned ��



I'm glad to annouce that there will be a Ceph Day on the 7th of February 2018 in Darmstadt. Deutsche Telekom will host the event. The day will start at 08:30 with registration and end around 17:45 with an one hour networking reception. 
We have already several very interesting presentations from SUSE, SAP, CERN, 42.com, Deutsche Telekom AG and Red Hat on the agenda and more to come. If you have an interesting  15-45 min presentation about Ceph, please contact me to discuss if we can add it to the agenda. Presentation language should be German or English.

I would like to thank our current sponsors SUSE and Deutsche Telekom and the Ceph Community  for the support. We are still in  negotiation with potential sponsors and will hopefully announce them soon.

The agenda will be available here soon. You can register through this link. Stay tuned for updates! See you in Darmstadt!

Today we’re releasing Krita 3.3.3. This will probably be the last stable release in the Krita 3 series. This release contains several bug fixes and one very important change for Windows users:

  • The Direct3d/Angle renderer is now the default for Intel users. Recent updates to the Intel display drivers have broken Krita on many more systems than before, so it’s better that everyone gets this workaround by default. If you experience decreased performance, you can always try to enable OpenGL again.

Other fixes and improvements include:

  • Fix an issue where it would not be possible to select certain blending modes when the current layer is grayscale but the image is rgb.
  • Set the OS and platform when reporting a bug from within Krita on Windows.
  • Make it possible to enter color values as percentage in the specific color selector
  • Add OpenGL warnings and make ANGLE default on Intel GPUs
  • Add an Invert button to the levels filter
  • Implement loading and saving of styles for group layers to and from PSD
  • Fix the erase mode not showing correctly when returning to the brush tool
  • Save the visibility of individual assistants in .kra files
  • Add an option to draw ruler tips as a power of 2
  • Disable autoscroll on move and transform tools.
  • Improve handling of native mouse events when using a pen and the Windows Ink API
  • Fix the focal point for the pinch zoom gesture
  • Fix loading netpbm files with comment.



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 3.3.3 on Ubuntu and derivatives. We are working on an updated snap.


Note: the gmic-qt and pdf 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.

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.

Kubuntu recently had to pull our 17.10 ISOs because of the so-called lenovo bug. Now that this bug is fixed, the ISOs have been respun, and so now it's time to begin to reseed the torrents.

To speed up the process, I wanted to zsync to the original ISOs before getting the new torrent files. Simon kindly told me the easy way to do this - cd to the directory where the ISOs live, which in my case is 

cd /media/valorie/Data/ISOs/


cp kubuntu-17.10{,.1}-desktop-amd64.iso && zsync http://cdimage.ubuntu.com/kubuntu/releases/17.10.1/release/kubuntu-17.10.1-desktop-amd64.iso.zsync

Where did I get the link to zsync? At http://cdimage.ubuntu.com/kubuntu/releases/17.10.1/release/. All ISOs are found at cdimage, just as all torrents are found at http://torrent.ubuntu.com:6969/.

The final step is to download those torrent files (pro-tip: use control F) and tell Ktorrent to seed them all! I seed all the supported Ubuntu releases. The more people do this, the faster torrents are for everyone. If you have the bandwidth, go for it!

PS: you don't have to copy all the cdimage URLs. Just up-arrow and then back-arrow through your previous command once the sync has finished, edit it, hit return and you are back in business.

I’d like to highlight some fixes and features that landed in the past week for our Usability and Productivity initiative:

  • Dragging a Firefox tab to the desktop now detaches it properly (KDE bug 337711)
  • Right-clicking on Discover’s icon exposes a new action that allows you to go straight to the Updates page (KDE Phabricator revision D9637)
  • You can now hide the “Comment” field in Dolphin’s Information Panel (KDE bug 365620)
  • Dolphin’s Properties window now has a tab that shows the same file metadata that the Information Panel does, for people who would prefer to access the information that way (KDE bug 384194)
  • Okular’s dialog box for when a PDF wants to be opened full screen is now presented more naturally (KDE bug 388511)
  • Okular can now Print .djvu files (KDE bug 388514)
  • Discover now de-duplicates categories from Flatpak (KDE bug 388313)
  • Discover no longer lets you scroll beyond the boundaries with the PageUp/PageDown keys (KDE bug 388745)
  • Discover app lists are now more compact (KDE Phabricator revision D9833)

These improvements were landed by KDE Developers Kai Uwe Broulik, Albert Astals Cid, Aleix Pol, Michael Heidelbach, and myself. And that’s not all; the entire KDE community has been busy landing many more bugfixes and features too–more than I can keep track of!

I want to especially focus on the last Discover change I mentioned above. After my last post about Discover, we got a lot of user feedback that people wanted greater density and to be able to see more apps at once. We’ve executed on a part of that, and this is now what Discover looks like if you make the window narrow:

I bring this up to highlight that we really do listen to users. Your feedback matters and we hear it! If you enjoy the results of our efforts, please consider becoming a contributor yourself or donating to KDE! In particular, we would love more contributors for our Usability and Productivity initiative. If you’re interested, please feel free to work on any of these bugs. Here are some that should be relatively easy. Happy coding!

January 11, 2018

We're kicking off 2018 with a new fantastic release of KStars for Windows & MacOS. Linux users should wait a few more days to get the release in the official PPA due to Canonical's Launchpad downtime because of the Meltdown and Spectre CPU vulnerabilities discovered recently.

KStars 2.9.1 aka "Lancaster" release is primarily a bugfix release, but it brings with it as well several new features and improvements to existing technologies.

Over the holidays, Robert Lancaster made significant improvements to KStars and this release is named in his honor. Thank you Robert for your awesome contributions to KStars and Open Astronomy community!

MacOS users gained a few additional drivers with this release including Apogee, QHY, and Meade DSI support!

Set Park Position

Setting a custom parking position used to involve going to INDI Control Panel and tinkering with a few settings before it is saved and active. With KStars 2.9.1, it is now a very accessible action. Simply click anywhere on the sky map and select your desired custom parking position.

The mount shall slew normally to the desired location and save it as the parking position. It will NOT park the mount, it will just save that position as the desired position. To park the mount, use the parking/unparking controls from the toolbar or from the sky map as you normally would.

Additional PHD 2 Support

Robert Lancaster built upon his previous changes to PHD2 to add a PHD2 command request list so that KStars can keep track of what it has asked PHD2 to do. This allowed the addition of several additional commands that could be used to control PHD2. Now, users can use the Ekos Guide Module to change the PHD2 exposure time, change the DEC guide settings, and get information about the guiding pulses sent to the mount. Also, after changing the Connect/Disconnect code, the PHD2 connection seems to be more reliable.

Dither support was improved by using the timeout variable in the Guide options to control how long KStars will wait after issuing a dither command before continuing. And in a related fix, the Guide module will use the setting in the guide options “Dither Failure Aborts Autoguide” to control whether a dither issue will cause the entire sequence to abort. The last two changes were due to the fact that if PHD2 did not send back a response after dithering, KStars would not complete the sequence and if PHD2 reported a guide error, it would abort the entire sequence regardless of the setting in the guide options. This should all now be fixed. Also he added a PHD2 Lost Lock Timer so that if it loses track of the guide star but then regains it within 5 seconds, then it won’t abort guiding.

Drift Graphics Updates

Robert Lancaster made several improvements to the graphs in the Guide Module. These changes will work whether the user is using PHD2 or the internal guider. First, the mount corrections were added to the Drift Graphics plot so that the user could see not just the RA and DEC error, but also the corrections that the mount is making in each axis.

Since this graph naturally has a different scale than the guide errors, a separate axis was added along with a slider to control its scale independently of the other axis. A set of controls was added at the bottom left so that each component could be added or removed from the graph independently. A slider was added so that the user could scroll through the guide history, or click the “Max” checkbox to lock the graph onto the latest point so it will autoscroll.

Also buttons were added for autoscaling the graphs, or exporting the guide data to a CSV file, clearing all the guide data, and for scaling the target in the Drift Plot. Finally, a label was added to the guide graph every time that a dither occurred so the user knows guiding was not bad at those points.

New 3D Star Profile and Data Visualization Tool

Robert Lancaster created a new KStars tool based on some QT Examples that would plot the Pixel Data shown in any of the KStars Image Views so that the user can inspect the data in a new manner. This is particularly useful for astrophotographers who want to visualize the profile of a star they are considering focusing or guiding on, for scientists who want to examine a cross section of their data to understand the relative brightness of different objects in the image, and for imagers who want to visually see what is going on in their data collection in a new way.

Note that in order to use this feature, KStars must be built with the Data Visualization module installed. For the Mac OS X DMG, users can start using this function right away. We are working to get it into the Windows exe and Linux PPA very soon so that these users can also use this function right out of the box. But for now, Linux users would have to build from source with Data Visualizations installed to have these features.

To use the new feature, the user needs to select the View Star Profile Icon in one of the Ekos Module Views, or in the Fitsviewer. Then, the region selected in the green tracking box will show up in the 3D graph as shown above. The user will then have one of the following toolbars at the bottom.

At the far left, the sample size combo box will let the user select the size of the image crop shown in the graph. This option is only available in the Summary Screen, the Align Module, and the Fitsviewer. The second combo box lets the user control whether they are selecting an individual item, or a row, or a column of pixels.

The slice button will be enabled if the user selects “Row” or “Column.” It will put the graph in slice mode so that the user can see a cross section view of the image. Third, is a check box that will open up two sliders that will let the user drag the slider to change the selection.

This is extremely useful in the slide mode to change the selected point and to move the cross section around the graph. It is also useful in the normal view when in “Explore Mode” so that the user can zoom around the image examining the pixels. 

Then the user has the “Zoom To” combo box, which the user can use to zoom the graph to different preset locations. Next is the combo box that lets the user select the color scheme of the graph. Then are the HFR and the Peak checkboxes, which will both turn on the HFR and Peak labels on each found star in the image, but will also display one of them at the bottom of the screen. And finally comes the Scaling checkbox, which enables the Scaling Side Panel. In that panel are three sliders, one to control the minimum value displayed on the graph or “black point”, one to control the maximum value displayed in the graph or the “white point,” and a third that is disabled by default that lets the user control the cutoff value for data displayed on the graph.

This third slider is very useful to get really big peaks out of the way so you can study the finer details in the image. There is a checkbox at the top to enable/disable the cutoff slider.

And finally at the bottom of the sliders is the “Auto scale” button. This will auto scale the sliders as you sample different areas in the image. It will not only optimize the display of the data, but will also affect the minimum and maximum points of the slider.

If you disable auto scale, then as you sample different parts of the image, they will be displayed at the same scale. A particularly useful way to use this is to select an area of your image using auto scale, tweak the min, max, and cutoff sliders to your liking, and then turn off the auto scale feature to explore other areas of the graph.

We’ve officially gone into String Freeze mode now! That’s developer speak for “No New Features, Honest”. Everything that’s going into Krita 4.0 now is in, and the only thing left to do is fixing bugs and refining stuff.

Given how much has changed between Krita 3 and Krita 4, that’s an important part of the job! Let us here repeat a very serious warning.


This doubles for files that contain text. Text in krita 3 is based on the ODT standard, text in Krita 4 is implemented using SVG. This beta is the first release that contains the new text tool. Here’s the low-down on the new text tool:

  • It’s not the text tool we wanted to create, and you could consider it as a stop-gap measure. Because of all the tax office worries, we simply didn’t have the time to create the fully-capable opentype-integrated text tool that we wanted to do.
  • But we couldn’t keep the old text tools either: they were broken, and based on ODT. We needed to have something that could replace those tools and that would would be functional enough for the simplest of use-cases, like text balloons in a comic.
  • So, what we’ve got is simple. There’s no vertical text for Chinese or Japanese yet, there’s no OpenType tweaking, there’s no fine typographic control.
  • The user interface is not final yet, and there are quite a few things that need polishing and fixing, and that we’re working on, but Krita 4’s text tool will be mostly what we’ve got now.

Apart from that…

This beta contains pretty much everything… We started working on some of these features, like the export feedback in 2016. Here’s a short list:

  • SVG vector system, with improved tools and workflow
  • New text tool
  • Python scripting
  • SVG import/export
  • Improved palette docker
  • Bigger brush sizes
  • Improved brush editor
  • Refactored saving and exporting: saving happens in the background, and export shows warnings when your file contains features that cannot be saved to a given file format
  • A fast colorize brush
  • The default pixel brush is much faster on systems with many cores
  • Lots of user interface polish

And there’s much more, but please download the builds, or build Krita and see for yourself!

One thing that is still in progress is updating the set of default brush presets: those aren’t in the beta yet, but they are in the nightly builds.

Platform Notes



  • The AppImage does not contain support for audio in animations
  • The AppImage does not have Python scripting
  • The AppImage does include the latest gmic-qt release


  • The app bundle does not contain gmic-qt
  • The app bundle does not contain Python scripting
  • The app bundle does not have support for importing PDF files



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.0 beta 1 on Ubuntu and derivatives.


Note: the gmic-qt and pdf 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.

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.

Today is a big day. The Nextcloud community is launching a new product and solution called Nextcloud Talk. It’s a full audio/video/chat communication solution which is self hosted, open source and super easy to use and run. This is the result of over 1.5 years of planing and development.

For a long time it was clear to me that the next step for a file sync and share solution like Nextcloud is to have communication and collaboration features build into the same platform. You want to have a group chat with the people you have a group file share with. You want to have a video call with the people while you are collaborative editing a document. You want to call a person directly from within Nextcloud to collaborate and discuss a shared file, a calendar invite, an email or anything else. And you want to do this using the same login, the same contacts and the same server infrastructure and webinterface.

So this is why we announced, at the very beginning of Nextcloud, that we will integrate the Spreed.ME WebRTC solution into Nextcloud. And this is what we did. But it became clear that whats really needed is something that is fully integrated into Nextcloud, easy to run and has more features. So we did a full rewrite the last 1.5 years. This is the result.

Nextcloud Talk can, with one click, be installed on every Nextcloud server. It contains a group chat feature so that people and teams can communicate and collaborate easily. It also has WebRTC video/voice call features including screen-sharing. This can be used for one on one calls, web-meetings or even full webinars. This works in the Web UI but the Nextxloud community also developed completely new Android and iOS apps so it works great on mobile too. Thanks to push notifications, you can actually call someone directly on the phone via Nextcloud or a different phone. So this is essentially a fully open source, self hosted, phone system integrated into Nextcloud. Meeting rooms can be public or private and invites can be sent via the Nextcloud Calendar. All calls are done peer to peer and end to end encrypted.

So what are the differences with WhatsApp Calls, Threema, Signal Calls or the Facebook Messenger?
All parts of Nextcloud Talk are fully Open Source and it is self hosted. So the signalling of the calls are done by your own Nextcloud server. This is unique. All the other mentioned solutions might be encrypted, which is hard to check if the source-code is not open, but they all use one central signalling server. So the people who run the service know all the metadata. Who is calling whom, when, how long and from where. This is not the case with Nextcloud Talk. No metadata is leaked. Another benefit is the full integration into all the other file sharing, communication, groupware and collaboration features of Nextcloud.

So when is it available? The Version 1.0 is available today. The Nextcloud App can be installed with one click from within Nextcloud. But you need the latest Nextcloud 13 beta server for now. The Android and iOS apps are available in the Google and Apple App Stores for free. This is only the first step of course. So if you want to give feedback and contribute then collaborate with the rest of the Nextcloud community.

More information can be found here https://apps.nextcloud.com/apps/spreed and here  https://nextcloud.com/talk







What are the plans for the future?
There are still parts missing that are planed for future version. We want to expose the Chat feature via an XMPP compatible API so that third party Chat Apps can talk to a Nextcloud Talk server. And we will also integrate chat into our mobile apps. I hope that Desktop chat apps also integrate this natively. for example on KDE and GNOME. This should be relatively easy because of the standard XMPP BOSH protocol. And the last important feature is call federation so that you can call people on different Nextcloud Talk servers.

If you want to contribute then please join us here on github:

Thanks a lot to everyone who made this happen. I’m proud that we have such a welcoming, creative and open atmosphere in the Nextcloud community so that such innovative new ideas can grow.

Akademy Poster by Jens Reuterberg

Akademy is the KDE Community conference. The 2018 edition is from Saturday 11th to Friday 17th August in Vienna, Austria. If you are working on topics relevant to KDE or Qt, this is your chance to present your work and ideas at the Conference. The days for talks are Saturday and Sunday, 11th and 12th. The rest of the week will be BoFs, unconference sessions and workshops.

What we are looking for

The goal of the conference section of Akademy is to learn and teach new skills and share our passion around what we're doing in KDE with each other.

For the sharing of ideas, experiences and state of things, we will have short Fast Track sessions in a single-track section of Akademy. Teaching and sharing technical details is done through longer sessions in the multi-track section of Akademy.

If you think you have something important to present, please tell us about it. If you know of someone else who should present, please encourage them. For more details see the proposal guidelines and the Call for Participation.

The submission deadline is 12th March, 23:59:59 CET.

Accommodation & Travel information

Information about how to get to Vienna and the recommended accommodation is now available on the Akademy website

About Akademy

For most of the year, KDE—one of the largest free and open software communities in the world—works on-line by email, IRC, forums and mailing lists. Akademy provides all KDE contributors the opportunity to meet in person to foster social bonds, work on concrete technology issues, consider new ideas, and reinforce the innovative, dynamic culture of KDE. Akademy brings together artists, designers, developers, translators, users, writers, sponsors and many other types of KDE contributors to celebrate the achievements of the past year and help determine the direction for the next year. Hands-on sessions offer the opportunity for intense work bringing those plans to reality. The KDE Community welcomes companies building on KDE technology, and those that are looking for opportunities. For more information, please contact The Akademy Team.

Dot Categories:

This blog post will get you started with Qt 3D Studio remote deployment to Qt 3D Viewer on Android devices. This feature enables making changes to your Qt 3D Studio presentation on your computer and seeing the changes live on the target device.

Qt 3D Studio Editor & Viewer with the remote connection feature

Qt 3D Studio Editor & Viewer with the remote connection feature

Setting Up the Target Device

To set up the target device for remote deployment, follow the steps below.

  1. Download Qt 3D Viewer from Google Play and install it on the target device.
  2. Run the Viewer.
  3. From the file menu, select File > Connect.
  4. Enter desired port or use default port, press OK.
  5. Connection information, IP address and port, will be displayed in the Viewer.

Connecting to the Target Device

To connect to the target device from Qt 3D Studio, follow the steps below.

  1. From the file menu, select File > Connect to Device.
  2. Enter the connection information displaying in the Viewer on the target device, then press OK.
  3. You are now connected. The Viewer on the target device should display Remote Connected.

Preview Presentation

To preview the presentation on the target device, press the Preview button in the Studio toolbar. After making changes to your presentation, press the Preview button again to see the changes on the target device.


The Preview button in Studio

Disconnecting from the Target Device

You can disconnect from the target device either by selecting File > Connect to Device from the Studio file menu, or by selecting File > Connect from the Viewer file menu.

The post Qt 3D Studio Remote Deployment on Android Devices appeared first on Qt Blog.

January 10, 2018

If you are using Qt and you need to run some code in a separate thread, chances are that you are using QThread for the job. QThread is a very old class in Qt, making its first appearance in Qt 2.2, released on the 22nd of September 2000. Its responsibility is to start a new thread, and let you execute code in that thread.

There are two main ways of running code in a separate thread using QThread:

  1. subclassing QThread and overriding run();
  2. creating a "worker object" (some QObject subclass) and connecting it to QThread signals.

Please refer to my Qt World Summit 2017 presentation (video) for more details about how to use these two functions. There are also lots of other documentation and blog posts available on the internet, discussing the pros and the cons of the two approaches.

Enter QThread::create()

In Qt 5.10 I have added another way to run some code in a new thread. Inspired by C++11's std::thread, I have introduced QThread::create, a factory function that creates a new QThread which will run a user-provided callable:

[sourcecode lang="cpp"]
QThread *thread = QThread::create([]{ runSlowCode(); });

The advantage of this approach is that it avoids creating a new QThread subclass manually for the sole purpose to override its run() member function and run some code.

Unlike std::thread, however, the newly-created thread is not automatically launched; the user is expected to start it with an explicit call to start(). This allows users to do some extra work before starting the thread, for instance, connect to its signals, set the name of the thread, or change its priority, as demonstrated by this snippet:

[sourcecode lang="cpp"]
QThread *thread = QThread::create(myFunction);

thread->setObjectName("WorkerThread"); // name to appear in ps, task manager, etc.
connect(thread, &QThread::started, gui, &Gui::threadHasStarted);


The user acquires ownership of the newly-created QThread object.

With a C++17 capable compiler it is also possible to pass extra arguments to QThread::create(): these arguments will be then passed to the function in the new thread, using the same semantics as std::thread's constructor. For instance:

[sourcecode lang="cpp"]
QThread *thread = QThread::create(myFunction, arg1, arg2);
// extra setup...
thread->start(); // calls myFunction in another thread, passing arg1 and arg2

That's it! I hope this will be useful to you. However, the API of QThread::create() is only half of the story. If you want to know more about what this apparently little patch meant for Qt, keep reading.

Implementation notes

In afterthought, the implementation of QThread::create is very simple. However, when doing the necessary research, I found a small oddity with the C++ Standard Library that deserves some attention.

The most important constraint I imposed on myself when writing QThread::create was to be as compatible as possible with std::thread's constructor semantics. If one reads the relevant section in the Standard (f.i. here), one can see that the actual semantics of the invocation are quite complex. The extra arguments to the function undergo a transformation (specified as DECAY_COPY), they're stored "somewhere", and finally the functor is invoked using the INVOKE function. Both DECAY_COPY and INVOKE are not actual Standard Library functions, but pseudo-functions formally defined elsewhere in the C++ Standard.

An oddity that I found during my research is that the C++11 Standard does not provide these building blocks to end-users (and by that I also include developers of other C++ libraries, like Qt). A way to use INVOKE for user code got added in C++17 with the std::invoke function; however, there is simply nothing ready-made that applies the DECAY_COPY transformation, and stores the callable and its decayed/copied arguments, and possibly even invokes the function with the right semantics.

The only workaround that I have found was to use a higher-level thread primitive provided by the Standard Library: std::async. std::async has the same invocation semantics as std::thread's constructor; it returns a std::future that we can use to examine the result.

We can force std::async to not spawn an additional thread and to run the callable only when asked to do so, by specifying the std::launch::deferred launch policy. std::launch::deferred allows a sort of lazy evaluation: the callable is invoked only when one tries to access the result (via the returned std::future object):

[sourcecode lang="cpp"]
auto future = std::async(std::launch::deferred, function, arg1, arg2);

// some time later, possibly in another thread:
future.get(); // calls the function with the arguments

This is exactly how QThread::create() is implemented: it calls std::async on the user-provided function and its arguments, and stores the returned std::future in an instance of an internal QThread subclass. This subclass overrides run(), which in turn simply calls get() on the future (see here and here). This machinery isn't zero-overhead, as the combination of std::async and std::future does way more than what we need, but it at least shifts the burden of the implementation from Qt onto the Standard Library.

The extra plumbing needed is the aforementioned std::invoke, which however is only available in C++17. Under a C++17 compiler, QThread::create() takes a callable and its arguments, whereas under a pre-C++17 compiler, QThread::create() only supports a callable (and no further arguments). In practice this isn't a big limitation, because one can always use a lambda to wrap the callable and its arguments, and then pass the lambda as the only argument.

Qt and the Standard Library ABI

The addition of QThread::create() to Qt was also possible because of a major policy change in Qt.

A little bit of history: up to and including version 4, Qt did not require the presence of a Standard Library implementation on the system (the configure script had a -no-stl option). From version 5.0 Qt started to require a working Standard Library implementation: the configure switch was dropped, and Qt code dealing with Standard Library types was compiled unconditionally. Qt itself started using Standard Library types (notably, containers) in its own implementation, mostly where such types provided more features or performance when compared to Qt's own versions.

However, Qt has never exposed Standard Library types from its public ABI: all functions taking or returning Standard Library types had to be inline (example). The main reason for doing so was to make the same build of Qt compatible across different Standard Library implementations (e.g. libc++ and stdlibc++, or two ABI-incompatible builds of the same implementation).

After lots of debate, this has finally changed in Qt 5.10: Qt is now allowed to expose Standard Library types from its public ABI. Users wishing to mix-and-match Standard Library implementations need to recompile Qt. (In other words, we've made this Someone Else's Problem).

What does this have to do with QThread::create()? As I explained before, the current implementation uses std::async under the hood. The std::future returned by std::async is then passed to an exported, out-of-line Qt function, which constructs and returns the result -- the QThread instance that runs the user-supplied function. (The reason for doing such a thing is because QThread is an exported polymorphic class. A subclass defined entirely inline would generate copies of its vtable / type_info in all the translation units using it, and this may cause problems.) Therefore, now std::future is part of Qt's own ABI; and I'm very glad I didn't have to re-implement it! continue reading

The post New in Qt 5.10: QThread::create appeared first on KDAB.


Hi and welcome to my blog! My name is Amit and with this blog I aim to keep you updated with my work at GCompris within Season of KDE 2018. After contributing for several months at GCompris, I applied for SoK 2018 and finally my proposal got selected among top 10 participants. I am very happy with the results I have got.

I will post here news, accomplishments and updates regarding my work. You can expect at least one post every two weeks and if anything comes up, I will post more often.

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.