December 11, 2017

Two months ago I attended to KDE Edu Sprint 2017 at Berlin. It was my first KDE sprint (really, I send code to KDE software since 2010 and never went to a sprint!) so I was really excited for the event.

KDE Edu is the an umbrella for specific educational software of KDE. There are a lot of them and it is the main educational software suite in free software world. Despite it, KDE Edu has received little attention in organization side, for instance the previous KDE Edu sprint occurred several years ago, our website has some problems, and more.

Therefore, this sprint was an opportunity not only for developers work in software development, but for works in organization side as well.

In organization work side, we discuss about the rebranding of some software more related to university work than for “education” itself, like Cantor and Labplot. There was a wish to create something like a KDE Research/Science in order to put software like them and others like Kile and KBibTex in a same umbrella. There is a discussion about this theme.

Other topic in this point was the discussions about a new website, more oriented to teach how to use KDE software in educational context than present a set of software. In fact, I think we need to do it and strengthen the “KDE Edu brand” in order to have a specific icon+link in KDE products page.

Follow, the developers in the sprint agreed with the multi operating system policy for KDE Edu. KDE software can be built and distributed to users of several OS, not only Linux. During the sprint some developers worked to bring installers for Windows, Mac OS, porting applications to Android, and creating independent installers for Linux distributions using flatpak.

Besides the discussions in this point, I worked to bring a rule to send e-mail to KDE Edu mailing list for each new Differential Revisions of KDE Edu software in Phabricator. Sorry devs, our mailboxes are full of e-mails because me.

Now in development work side, my focus was work hard on Cantor. First, I made some task triage in our workboard, closing, opening, and putting more information in some tasks. Secondly, I reviewed some works made by Rishabh Gupta, my student during GSoC 2017. He ported the Lua and R backend to QProcess and it will be available soon.

After it I worked to port Python 3 backend to Python/C API. This work is in progress and I expect to finish it to release in 18.04.

Of course, besides this amount of work we have fun with some beers and German food (and some American food and Chinese food and Arab food and Italian food as well)! I was happy because my 31 years birthday was in the first day of the sprint, so thank you KDE for coming to my birthday party full of code and good beers and pork dishes. ��

To finish, it is always a pleasure to meet the gearheads like my Spanish friends Albert and Aleix, the only other Mageia user I found personally in my life Timothée, my GSoC student Rishabh, my irmão brasileiro Sandro, and the new friends Sanjiban and David.

Thank you KDE e.V for provide resources to the sprint and thank you Endocode for hosting the sprint.

A software developer's life can get lonely. Developers spend a lot of time immersed in their code, and often don't get to see the direct impact of their work on the users. That is why events like Randa Meetings are necessary. They help build bonds within the community and show the developers that their work is appreciated.

Randa Meetings are crucial to the KDE community for developer interaction, brainstorming, and bringing great new things to KDE. --- Scarlett Clark

Randa Meetings are a yearly collection of KDE Community contributor sprints that take place in Randa, Switzerland. With origins dating back to a Plasma meeting in 2009, Randa is one of the most important developer-related events in the community.

View from Randa. Photo by Gilles Caulier, CC BY 2.0

This year, Randa Meetings were held from September 10 to September 16, and were centered around a meaningful theme - accessibility.

Accessibility in Free and Open Source Software

Accessibility is incredibly important, yet so often neglected in the process of software development, and implemented almost as an afterthought. Users with disabilities and impairments often find themselves excluded from using the software, and prevented from participating in activities that the rest of us take for granted. Essentially, the software makes them feel as if they don't matter.

To remedy this, many governments enforce laws requiring software to be accessible. There are also accessibility standards, guidelines, and checklists to help developers make their software accessible to all.

FOSS communities and projects have the potential to play a major role in driving software accessibility efforts because of their open nature. People with disabilities can communicate directly with developers, report issues, and request features that they need. Proprietary products are rarely this open to feedback, not to mention the fact they are often very expensive.

Accessibility Settings module in Plasma 5

Assistive technology covers a wide range of products and solutions: from screen magnifiers, screen readers, and text prediction methods to text-to-speech interfaces, speech recognition software, and simplified computer interfaces. There are also advanced solutions like 3D-printed prosthetic limbs, and those that allow controlling the mouse by moving the head or just the eyes.

The best thing about all this technology is that it benefits everyone. Although people usually associate the word "accessibility" with hearing or visually impaired people, assistive technology can make life easier for many other groups: dyslexic or illiterate people, cognitively disabled people, the elderly, anyone with limited mobility or just bad eyesight.

The analogy is clear with wheelchair-accessible spaces, which are useful to parents with baby strollers, people with bicycles and shopping carts, and delivery drivers. Likewise, improving keyboard navigation, image and color contrast, and text-to-speech tools results in satisfaction among non-disabled users. Making software accessible means making software better.

Making KDE Software More Accessible

Generally speaking, there are two ways to make software accessible: either by building special accessibility-focused tools from scratch, or by implementing accessibility features and improvements into existing applications. The latter is what the Randa Meetings 2017 were all about.

digiKam with David Edmundson from Plasma in the background.
Photo by Gilles Caulier, CC BY 2.0

The developers created a useful KWin plugin that can simulate different types of color blindness. This will help in all future accessibility efforts, as it helps developers understand what their color schemes will look like to visually impaired users.

KMyMoney was made more accessible via improvements to keyboard navigation. New keyboard shortcuts were added, and others simplified to make them easier to use.

Randa Meetings 2017 were made special by Manuel, a visitor from Italy who stayed at the Randa house during the sprint. Manuel is a deaf user, and he took the time to explain the problems that hearing-impaired users encounter with KDE software, and software in general. His feedback was extremely valuable in the context of the sprint's theme, and helped developers come up with accessibility-oriented solutions.

Meeting in Randa with other participants makes you aware of deficiencies, possibilities, and needs. For a newcomer, like myself, it was also a chance to meet some community members, see what kind of people build KDE software, and take a look behind the scenes. --- Lukasz Wojnilowicz

Apart from fixing individual applications, a lot of work was done on the Plasma desktop environment itself. Accessibility-related improvements include the ability to navigate the Plasma panel using voice feedback and the keyboard. The following video demonstrates this feature in action:

KRunner was made completely accessible, and this change is visible in Plasma 5.11. The Orca Screen Reader works well with KRunner, and can read the entered query, as well as let the user know which element of the interface is currently focused.

There was also a round of discussions on best practices for accessibility in KDE software. When testing software, the developers should try to use it only with their keyboard, and then only with the mouse. Too much customization is not a good idea, so it should be avoided, especially when it comes to colors, fonts, and focus handling.

Another good practice is to test the application with a screen reader. This experience should highlight potential issues for disabled users. In the end, it all comes down to empathy - being able to put yourself in the user's shoes, and the willingness to make your software available to as many people as possible, without excluding anyone.

More Plans and Achievements from the Randa Meetings 2017

Of course, the developers worked on so much more than just accessibility. The KDE PIM team discussed the results of their KMail User Survey, and tackled the most pressing issue reported by the uses - broken and unreliable search. They also ported the entire Kontact codebase away from the obsolete KDateTime component.

Lukasz Wojnilowicz from KMyMoney and Volker Krause
from KDE PIM. Photo by Gilles Caulier, CC BY 2.0

KMyMoney saw some important changes. All plugin KCM modules were ported to KF5. The backup feature is, well, back up and available to use, and database loading was improved so as to prevent the incompatibility between new and old KMyMoney files.

After successfully participating in Google Summer of Code, the digiKam team gathered in Randa to further polish the new code contributed by students. They also worked on the media server functionality, which allows users to share their photo collections across different devices (smartphones, tablets, TVs...) using DLNA.

Scarlett Clark (KDE CI), Emmanuel LePage (Ring), Simon Frei
(digiKam) and David Edmundson discussing Plasma Accessibility.
Photo by Gilles Caulier, CC BY 2.0

Marble Maps now has a new splash screen, and the entire interface of the Bookmarks dialog is responsive to touch. There are plans to implement a better text-to-speech module for navigation.

The Public Transport Plasma applet has been completely rewritten as a Kirigami application. The applet's UI is now much more flexible and easier to adapt to mobile devices.

The developers of Kube worked on resolving an annoying issue with live queries which slows down email synchronization, especially when there are thousands of emails. They also discussed the possibility of implementing an HTML composer to edit emails in Kube, and made plans for GPG implementation. In collaboration with developers from other KDE projects, they explored the options for making Kube cross-platform, and looked for the best way to build Kube on macOS and Windows. Finally, they implemented a visualization in the configuration dialog which indicates when the user input is invalid in configuration fields.

Last but not least, Kdenlive received color correction improvements, and the developers worked on bringing back the popular TypeWriter effect. They also fixed the import of image sequences, worked on porting Kdenlive to Windows and macOS, and removed the warning about missing DVD tools that used to appear when starting Kdenlive for the first time.

Looking Forward to the Next Randa Meetings

With another successful Randa Meetings behind us, we can start planning for the next session.

If you like the work our developers are doing, you can directly support it by donating to KDE. You can also contribute to KDE and make an impact on the users by joining our mentored project called Season of KDE.

Who knows, maybe in the future you too will attend the Randa Meetings!

Could you tell us something about yourself?

I’m Rytelier, a digital artist. I’ve had an interest in creating art for a few years, I mainly want to visualize my original world.

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

Currently I do only personal work, but I will look for some freelance job in the future.

What genre(s) do you work in?

I work mainly in science fiction – I’m creating an original world. I like to try various things, from creatures to landscapes and architecture. There are so many things to design in this world.

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

It’s hard to point out certain artists, there are so many. Mainly I get inspired by fantasy art from the internet, I explore various websites to find interesting art.

I recommend looking at my favourites gallery, there are many works that inspire me.

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

It was years ago, I’ve got interested in the subject after I saw other people’s work. It was obviously confusing, how to place strokes, how to mix colors, and I had to get used to not looking at my hand when doing something on the tablet.

What makes you choose digital over traditional painting?

I like the freedom and flexibility that digital art gives. I can create a variety of textures, find colors more easily and fix mistakes.

How did you find out about Krita?

I saw a news item about Krita on some website related to digital art and decided to try it.

What was your first impression?

I liked how many interesting brushes there were. As time went on I discovered more useful features. It was surprising to find out that some functions aren’t available in Photoshop.

What do you love about Krita?

It has many useful functions and very high user convenience. I love the brush editor – it’s clean and simple to understand, but powerful. The dynamics curve adjustment is useful, the size dependent brush with sunken curve allows me to paint fur and grass more easily.

Also different functional brush engines. Color smudge is nice for more traditional work, like mixing wet paint. Shape brush is like a lasso, but better because it shows the shape instantly, without having to use the fill tool. Filter brush is nice too, I mainly use it as sharpen and customizable burn/dodge. There are also ways to color line art quickly. For a free program that functionality is amazing — it would be amazing even for a paid program! I like this software much more than Photoshop.

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

The performance is the thing I most want to see improved for painting and filters. I’m happy to see multi-threaded brushes in the 4.0 version. Also I would like more dynamic preview on applying filters like the gradient map, where it updates instantly when moving the color on the color wheel. It annoys me that large brush files (brushes with big textures) don’t load, I
have to optimize my textures by reducing the size so the brush can load.

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

The amount of convenience is very high compared to other programs. The amount of “this one should be designed in a better way, it annoys me” things is the smallest of all the programs I use, and if something is broken, then most of these functions are announced to improve in 4.0.

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

It’s hard to pick a favourite. I think this, because I challenged myself in this picture and they are my original character, which I like a lot.

What techniques and brushes did you use in it?

I use brushes that I’ve created myself from resources found on the internet and pictures scanned by myself. I like to use slightly different ways of painting in every artwork, still looking for techniques that suit me best. Generally I start from sketch, then paint splatter going all over the canvas, then adding blurry forms, then adding details. Starting from soft edges allows me to find good colors more easily.

Where can people see more of your work?
I will open galleries in other sites in the future.

Anything else you’d like to share?

I hope that Krita will get more exposure and more people, including professionals, will use it and will donate to its development team instead of buying expensive digital art programs. Open source software is having a great time, more and more tools are being created that replace these expensive ones in various categories.

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

Actualización de diciembre del 2017 de KDE Frameworks, el motor de Plasma y KDE

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

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

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

Más información: KDE

¿Qué es KDE Frameworks?

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

Actualización de octubre del 2017 de KDE Frameworks

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

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

December 10, 2017

Today’s daily ISO for Bionic Beaver 18.04 sees an experimental switch to the Breeze-Dark Plasma theme by default.

Users running 18.04 development version who have not deliberately opted to use Breeze/Breeze-Light in their systemsettings will also see the change after upgrading packages.

Users can easily revert back to the Breeze/Breeze-Light Plasma themes by changing this in systemsettings.

Feedback on this change will be very welcome:

You can reach us on the Kubuntu IRC channel or Telegram group, on our user mailing list, or post feedback on the (unofficial) Kubuntu web forums

Thank you to Michael Tunnell from for kindly suggesting this change.

Hace tiempo que tenía pendiente esta entrada y finalmente he encontrado el hueco. Se trata de presentaros PlasmaTube, un plasmoide sencillo con el que tendrás la infinita lista de vídeos de Youtube disponible en tu escritorio Plasma. Con este plasmoide ya serán 82 los presentados en el blog.

PlasmaTube – Plasmoides de KDE (82)

Si tienes una cuenta de Youtube puedes disfrutar de sus vídeos en tu entorno Plasma favorito, es decir, en el fondo de escritorio. Para ello simplemente debes instalar PlasmaTube, un plasmoide creado por Zanturik con el que podrás:


  • Reproducir cualquier vídeo de youtube
  • Realizar búsquedas entre vídeos, canales o listas de reproducción
  • Tener diferentes configuraciones predefinidas para cada actividad, incluso para un PlasmaTube incrustado en una barra de tareas.
  • Posibilidad de editar y ordenar los resultados (settings -> youtube channels -> click and hold, than drag)
  • Definir el número de vídeos por canal o lista de reproducción en los resultados de las búsquedas

Su instalación es muy sencilla ya que se realiza desde el instalador de plamoides desde la red, como explica en la siguiente entrada hacer unos días.

En definitiva, un plasmoide simple pero completo para disfrutar de la inmensidad de youtube en tu escritorio Plasma KDE.

Y como siempre digo, si os gusta el plasmoide podéis “pagarlo” de muchas formas en la nueva 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 sencilla de colaborar con el gran proyecto del Software Libre y que en el blog dedicamos un artículo.

December 09, 2017

The Elisa team is happy to release the first alpha release of a future 0.1 version of the Elisa music player.


Elisa is a music player designed to be simple and nice to use.

Elisa allows to browse music by album, artist or all tracks. The music is indexed using either a private indexer or an indexer using Baloo. The private one can be configured to scan music on chosen paths. The Baloo one is much faster because Baloo is providing all needed data from its own database. You can build and play your own playlist.

It is available in source form only at KDE also provides regular flatpak and windows builds. The windows builds are provided by and are using Craft. Thanks to the people in the flatpak and windows teams. A binary package is provided for Fedora thanks to Robert-André Mauchin. Other Linux distributions may provide binary packages from the git repository (as far as I know, there is an AUR package and a package for Neon).

The development is still continuing and we will regularly release an alpha version until we have completed review by other KDE developers. We plan to move to kdereview as soon as we have finished a few missing features.

For the curious reader, the phabricator workboard of Elisa is a good way to know what is happening (

Any help is very much welcome. We have open tasks for code but also for design.

Lo he dicho muchas veces, me encantaría hacerme eco de todos los Podcast Linux pero no tengo el tiempo necesario para ello. Pero cuando hay uno tan importante como el que hoy no puedo más que buscar un hueco. Hoy os traigo el Linux Connexion con Aleix Pol, un magnífico podcast donde se habla de las posibilidades del mundo Linux en el mundo de los móviles.

Linux Connexion con Aleix Pol

Linux Connexion con Aleix PolPodcast Linux es un podcast quincenal producido por Juan Febles para acercar GNU/Linux al usuario de ordenadores de a pie, con un estilo cordial y amigable. Este podcast pertenece a la red de .

En el momento de escribir este artículo, Podcast Linux lleva ya 40 episodios donde se han tratado todo tipo de temas: distribuciones, conocimiento libre, hardware, asociaciones, educación, ciberseguridad, privacidad, etc.

En esta ocasión le ha dedicado un episodio al gran Aleix Pol aunque creo que es mejor que lo presente el gran Juan Febles, presentados del podcast y comunicador extraordinario:

“Bienvenido a otro Linux Connexion, en esta ocasión el número 40, de Podcast Linux. Un cordial saludo de quien te habla, Juan Febles. Hoy nos acompañará Aleix Pol y será el punto y seguido del anterior episodio 39 GNU/Linux y móviles. Aleix es desarrollador, vicepresidente de KDE Internacional y miembro activo en Plasma Mobile. Conoce desde dentro la realidad del tema que vamos a tratar.”

De esta forma, a lo largo de poco más de una hora Aleix analiza el momento de GNU/Linux en el mundo de los móviles, comenta las posibilidad de Plasma Mobile y sus posibilidades de futuro, habla del gran KDE Connect y del trabajo realizado por el grupo de Comunidad de KDE España.

Además, realiza la gran reflexión del podcast que me atrevo a resumir en “Si quieres que algo pase en el mundo GNU/Linux, no seas un mero espectador y aporta tu grano de arena con código, promoción o con dinero” (no son palabras textuales pero si es la idea general).

No obstante, lo mejor es que escuches el podcast completo y que saques tus propias conclusiones de uno de los mejores audios que te puedes llevar a tu reproductor sobre GNU/Linux.

Aprovecho para animaros a seguir Podcast Linux en algunos de los canales de comunicación que tiene y que tan bien controla en gran Juan Febles. Seguro que encontráis alguno que os venga bien:

Twitter: @podcastlinux

December 08, 2017

Another month passed, just like that. I spent last week holed up with some KDE people in the hills, watching the snow come down. While they did impressive things to the KDE codebase, I hacked on Calamares. Since my last post on the topic, I’ve been running a roughly every-other-week release schedule for the Calamares 3.1-stable branch. We’ve just reached 3.1.10. The reason for these stable releases is small bugfixes, minor polishing, and occasional non-interfering features.

Each release is announced on the Calamares site, and can be found on the Calamares GitHub page.

Calamares isn’t a KDE project, and aims to support whatever Linux distro wants to use it, and to configure the stuff that is needed for that distro. But when feature requests show up for KDE integration, there’s no special reason for me to reject them — as long as things can remain modular, the SKIP_MODULES mechanism in Calamares can avoid unwanted KDE Frameworks dependencies.

One new module in development is called “Plasma Look-and-Feel” (plasmalnf) and the purpose there is to configure the look-and-feel of Plasma. No surprise there, but ther point is that this can be done during installation, before Plasma is started by the (new) user on the target system. So kind of like the Look-and-Feel KCM, but entirely outside of the target environment. The UI is more primitive, more limited, but that’s the use-case that was asked for. I’d like to thank the Plasma developers for helping out with tooling and guiding me through some of the Plasma code, and deployers of Calamares (that is, distro’s) can look forward to this feature in the 3.2 series.

Speaking of Calamares 3.2, I’m intending to put out an RC fairly soon, with the features as developed so far. There will probably be a few RCs each of which integrates a new feature branch (e.g. a giant requirements-checking rewrite) with 3.2.0 showing up for real in the new year.

December 07, 2017

We’re now running a Kube program with Kolab Now where you can get a basic Kolab Now account now, and see it’s features grow together with Kube, while the price remains the same. To take advantage of that offer, install the Kolab Now flatpak and signup through Kube.

  • Fixed a problem where emails with a header larger than 8kb would not be parsed correctly.
  • Added a Kolab Now signup capability to the Kolab Now settings.
  • Added merging of log entries of the same type so you don’t end up with multiple errors.
  • Added a dedicated error view for some classes of errors: Blogpost
  • Added support for PGP encryption: Blogpost
  • Fixed opening of attachments in the flatpak(s) (/tmp needed to be shared with the host system).
  • Added a dockercontainer to the kube repository that is used for CI and can be used for development.
  • Added ASAN and LSAN checkers (LLVM based memory/leak checkers) to sink and fixed various related issues.
  • Created a stresstest for sink which allows to continously run synchronizations and queries. This is used to trigger hard to find crashes.

Kube Commits, Sink Commits

Previous updates

More information on the Kolab Now blog!

“Kube is a modern communication and collaboration client built with QtQuick on top of a high performance, low resource usage core. It provides online and offline access to all your mail, contacts, calendars, notes, todo’s and more. With a strong focus on usability, the team works with designers and UX experts from the ground up, to build a product that is not only visually appealing but also a joy to use.”

For more info, head over to:

December 05, 2017

We are happy to release a new SDDM with a few improvements.

SDDM is a Qt based graphical login manager developed in a collaborative fashion by people from Liri, KDE and LXQt.

This new version include the following changes:

* Added possibility to change border width of ComboBox widget.
* Added missing utmp/wtmp/btmp handling.
* Make greeter see icons set by AccountsServices.
* Fix sddm.conf man page syntax error and update.
* Fix ComboBox widget.
* Fix connection of PropertiesChanged event for LogindSeat.
* Avoid race conditions with Xsetup.
* Update de translation.
* Update lt translation.
* Update zh_TW translation.
* Adjust order of components in the default PATH.
* Set default input method to qtvirtualkeyboard.

Download it here.

While it is possible to draw scenes with almost unlimited numbers of lights using deferred rendering in Qt 3D, the default materials in Qt 3D Extras have been limited to eight lights because they are tied to forward rendering. Although we apply a few tricks that allow you to define more than eight lights in the scene, we only select the eight closest lights when rendering.

In the scene below, we have defined 100 lights that float around, but because only 8 of them are in use at the time and you can see how they pop in and out:

Although it’s possible to support more lights in other pipelines (this is for instance the case with the Qt 3D Studio Runtime), we also want the default materials in Qt 3D Extras to be able to use a larger number of lights, even when used with forward rendering.

The reason behind the current limit is that we need to support a range of OpenGL architectures, including some which are quite limited in terms of how much uniform data can be passed to the shader. We therefore need to pass a small array of light structs to the shader and loop over the lights in the fragment shader. Unfortunately, such loops are also very expensive on hardware with limited resources because they compile to a large number of shader program instructions. Sometimes so many that the resulting shader program won’t compile at all.

We have therefore started work on a solution that will both allow us to increase the number of lights on beefy hardware and at the same time reduce the number of shader program instructions on weaker hardware. It is based on Qt 3D’s new internal shader graph, which was recently introduced by Kevin Ottens from KDAB.

The shader graph is a game changer for Qt 3D. It allows us to build shaders dynamically with a structure similar to the material graphs you find in many modern 3D modeling applications. Each node in the graph can be thought of as a function – it is defined as a computation, takes a set of input values, and produces output values. For instance, a surface node can take the incoming and outgoing angles of light, the light color, and the surface color, and compute the resulting light contribution. By connecting nodes in the graph, you define the flow of computations in the shader program, which is translated to instructions in a programming language. Because all the computations are abstract, they can easily be translated to many different shader languages (or dialects), making it trivial to produce the same material definitions for different architectures.

In terms of increasing the number of lights, the great thing about the shader graph is that we can easily define a shader node for each of the lights in the scene. The graph then results in the right number of light calculations when converted to shader code. Instead of having a for loop inside the shader itself, we loop over the lights when the shader is generated. This is basically unrolling the old loop, which is way more efficient and allows us to have a much higher number of lights.

I am currently working on a prototype where we have moved the lighting system on top of the shader graph. While this work is still highly experimental, it is already producing some promising results. Here’s the same scene as above, but this time we are actually seeing 100 lights in use at the same time:

Before this becomes part of the default materials in Qt 3D Extras, we also want to change how lights are gathered in a scene and passed on to the shaders. Currently, the light gathering is tightly coupled with the rendering code, but we want to reduce the number of assumptions we make and give you more control over how light information is passed to your shaders. In turn, this will also make it easier to create applications that can switch between rendering modes, for instance if you want to support both forward and deferred rendering of the same scene

If this sounds interesting for your applications, feel free to share thoughts on how you would like to work with lights in your code.

The post Increasing the number of lights in Qt 3D appeared first on Qt Blog.

December 03, 2017

The KTextEditor Framework uses the syntax highlighting files provided by the KSyntaxHighlighting Framework since the  KDE Frameworks release 5.28.

The KSyntaxHighlighting Framework implements Kate’s highlighting system and meanwhile is used in quite some applications (e.g. LabPlot, KDE PIM). What is quite nice is that the KSyntaxHighlighting framework is nicely unit tested. And while we do not have tests for all highlighting files, we still provide some quality assurance through a compile time checker.

How does it work? Well – in former times, Kate loaded all highlighting .xml files from disk (through the KTextEditor framework). This lead to a slow startup over time, since there are >250 .xml files that needed a stat system call at startup.

With the KSyntaxHighlighting Framework, all these xml files are compiled into a Qt resource (qrc file), that then is included into the KSyntaxHighlighting library.

In order to create the Qt resource file, we need to iterate over all available xml files anyways. So what happens is that we take this opportunity and also scan the highlighting files for common mistakes.

As of today, we are checking the following:

  1. RegExpr: A warning is raised, if a regular expression has syntax errors.
  2. DetectChars: A warning is raised, if the char=”x” attribute contains more or less than one character, e.g. when char=”xyz”, or char=”\\” (no escaping required), or similar.
  3. Detect2Chars: Same as DetectChars, just for char=”x” and char1=”y”.
  4. Keyword lists: A warning is raised, if a keyword entry contains leading or trailing spaces. Additional trimming just takes time.
  5. Keyword lists: A warning is raised if a keyword list is unused.
  6. Keyword lists: A warning is raised if multiple keyword lists use the same me (=identifier).
  7. Keyword lists: A warning is raised if a non-existing keyword list is used.
  8. Contexts: A warning is raised, if a non-existing context is referenced.
  9. Contexts: A warning is raised, if a context is unused.
  10. Contexts: A warning is raised, if multiple contexts have the same name (identifier clash).
  11. Attributes: A warning is raised, if non-existing itemData is used.
  12. Attributes: A warning is raised, if multiple itemDatas use the same name (identifier clash).
  13. Attributes: A warning is raised, if an itemData is unused.

This list helps us nicely to catch many mistakes at compile time even before running unit tests.

However, there is still work to do, since some of the files still contain one or more of the above issues. The current todo-list looks as follows (updated on 2017-12-04):

Reference of non-existing keyword list:
- "asp.xml": QSet("Others")
- "template-toolkit.xml": QSet("Others")

Duplicate contexts:
- "diff.xml": "File"
- "objectivecpp.xml": "Preprocessor"

Reference of non-existing itemData attributes:
- "haml.xml": QSet("Array", "Escaped Text", "Ruby embedded in haml")
- "lilypond.xml": QSet("Tremolo")
- "metafont.xml": QSet("Verbatim", "Tex", "Bullet")
- "relaxng.xml": QSet("Entity Reference")
- "rhtml.xml": QSet("RUBY RAILS ERB Text")
- "rmarkdown.xml": QSet("Markdown", "Document Headers")
- "stata.xml": QSet("String2")

Incorrect DetectChar and Detect2Chars:
- "xmldebug.xml" line 130 'char' must contain exactly one char: "\"(\\s+|$)"
- "xmldebug.xml" line 135 'char' must contain exactly one char: "'(\\s+|$)"
- "xmldebug.xml" line 373 'char' must contain exactly one char: "\"(\\s+|$)"
- "xmldebug.xml" line 378 'char' must contain exactly one char: "'(\\s+|$)"
- "xmldebug.xml" line 415 'char' must contain exactly one char: "\"(\\s+|$)"
- "xmldebug.xml" line 420 'char' must contain exactly one char: "'(\\s+|$)"
- "xmldebug.xml" line 467 'char' must contain exactly one char: "\"(\\s+|$)"
- "xmldebug.xml" line 472 'char' must contain exactly one char: "'(\\s+|$)"

Unused contexts:
- "ample.xml": QSet("Preprocessor", "Define")
- "gcc.xml": QSet("GNUMacros")
- "ruby.xml": QSet("RDoc Label")
- "tcsh.xml": QSet("HereDocIQ", "HereDocNQ", "HereDocINQ", "HereDocQ", "FindCommentsParen")
- "xmldebug.xml": QSet("44:Enumeration")

Unused keyword lists:
- "ample.xml": QSet("dvafct", "icprops", "sgfct")
- "ansforth94.xml": QSet("attention")
- "css.xml": QSet("mediatypes_op")
- "dosbat.xml": QSet("not", "else")
- "euphoria.xml": QSet("constants")
- "freebasic.xml": QSet("Assembly Operators")
- "fsharp.xml": QSet("symbols")
- "ilerpg.xml": QSet("pkeywords", "evalopcodes8")
- "metafont.xml": QSet("EnvDelimiters", "notDefined")
- "pango.xml": QSet("int_attributes", "plain_attributes", "endtags", "color_attributes", "tags")
- "pony.xml": QSet("types", "literal")
- "powershell.xml": QSet("operators", "attributes")
- "scss.xml": QSet("mediatypes_op")
- "vhdl.xml": QSet("forOrWhile", "directions")
- "xonotic-console.xml": QSet("Aliases")
- "build/frameworks/syntax-highlighting/data/css-php.xml": QSet("mediatypes_op")
- "prolog.xml": QSet("list+is_list non-ISO", "lists ISO", "listing non-ISO", "directives non-ISO", "lists non-ISO", "terms non-ISO", "streams deprecated")

Fixing these issues is quite some work and sometimes even a bit tricky. So if you want to get your hands dirty, help is always welcome. Please send your patches to us using the syntax-highlighting repository on Phabricator ��

December 01, 2017

It‘s a common usecase to share Files or Content from native Android or iOS Apps with other Apps on your phone. So I thought this would be an easy task to add sharing to my mobile Apps built with QtQuickControls2.

Found the Blog from Eskil Abrahamsen Blomfeld about Intents with Qt for Android, part 1. Please read that Blog to learn about Android Intents, Qt Android Extras, JNI and HowTo use it from Qt. All of this was new to me – never did JNI before. Also I‘m not an experienced native developer for Android or iOS – that‘s the reason why I‘m using Qt for mobile App development.

I also found Share on iOS and Android using QML, where I learned HowTo share Text and a URL and HowTo structure a QtCreator project for Android and iOS with native code integration.

Unfortunately all of this didn‘t help me to share Files on Android or iOS from Qt mobile Apps.

For a DropBox-like project at customer site I needed sharing:

  • download Files from cloud
  • store Files in App sandbox data
  • view or edit Files in other Apps
  • print Files to local Printer

It took me some time and thanks to much help from other developers at Qt Forum and Slack (QtMob) I found ways to solve my use-cases.

The hardest part was the ugly JNI and Obj-C syntax ��

Hopefully my experiences will make it easier for others to integrate Sharing-functionality into their Android or iOS Apps.

Here‘s my Example App at Github.

The Example App demonstrates:

  • Share Text and URL
  • View File
  • Edit File
  • Send File as Stream to …

To easy understand the complex structure please take a look at this Overview:


UI: SwipeView with some Tabs. Each Tab contains a Page with some Buttons to test features.


Share Text and URL is the easiest one:


ShareUtils is registered as „shareUtils“:

void ApplicationUI::addContextProperty(QQmlContext *context)
    context->setContextProperty("shareUtils", mShareUtils);

Click on the Button to share Text and URL:

Button {
    text: qsTr("Share Text and Url")
    onClicked: {

Here‘s the share() method:

Q_INVOKABLE void share(const QString &text, const QUrl &url);
void ShareUtils::share(const QString &text, const QUrl &url)
    mPlatformShareUtils->share(text, url);

ShareUtils delegates this to PlatformShareUtils:

  • AndroidShareUtils on Android
  • IosShareUtils on iOS

The magic to detect the right class can be found in ShareUtils:

#if defined(Q_OS_IOS)
    mPlatformShareUtils = new IosShareUtils(this);
#elif defined(Q_OS_ANDROID)
    mPlatformShareUtils = new AndroidShareUtils(this);
    mPlatformShareUtils = new PlatformShareUtils(this);

The Compiler knows the Platform you‘re running on and instantiates the matching platform specificClass.


void AndroidShareUtils::share(const QString &text, const QUrl &url)
    QAndroidJniObject jsText = QAndroidJniObject::fromString(text);
    QAndroidJniObject jsUrl = QAndroidJniObject::fromString(url.toString());
    jboolean ok = QAndroidJniObject::callStaticMethod("org/ekkescorner/utils/QShareUtils",
                                              jsText.object(), jsUrl.object());
    if(!ok) {
        emit shareNoAppAvailable(0);

QAndroidJniObjects are created for text and url and a Method from will be called:

    public static boolean share(String text, String url) {
        if (QtNative.activity() == null)
            return false;
        Intent sendIntent = new Intent();
        sendIntent.putExtra(Intent.EXTRA_TEXT, text + " " + url);
        // Verify that the intent will resolve to an activity
        if (sendIntent.resolveActivity(QtNative.activity().getPackageManager()) != null) {
            return true;
        } else {
            Log.d("ekkescorner share", "Intent not resolved");
        return false;

In our we create the Intent with ACTION_SEND and EXTRA_TEXT and start the Activity using QtNative.activity().

It‘s important to test if the Intent can be resolved – otherwise your App will crash.

Here‘s the iOS implementation:

void IosShareUtils::share(const QString &text, const QUrl &url) {
    NSMutableArray *sharingItems = [NSMutableArray new];
    if (!text.isEmpty()) {
        [sharingItems addObject:text.toNSString()];
    if (url.isValid()) {
        [sharingItems addObject:url.toNSURL()];
    // get the main window rootViewController
    UIViewController *qtUIViewController = [[UIApplication sharedApplication].keyWindow rootViewController];
    UIActivityViewController *activityController = [[UIActivityViewController alloc] initWithActivityItems:sharingItems applicationActivities:nil];
    if ( [activityController respondsToSelector:@selector(popoverPresentationController)] ) { // iOS8
        activityController.popoverPresentationController.sourceView = qtUIViewController.view;
    [qtUIViewController presentViewController:activityController animated:YES completion:nil];

In this case we‘re using UIActivityViewController to get the share options displayed.

Let‘s take a look HowTo view or edit Files. My Example App contains an Image and a PDF File in assets:


At first start of the Example App we copy these files from Assets to (QstandardPaths::AppDataLocation)/my_share_files. This simulates that you have downloaded the Files from your Cloud or WebService.

See all the details in the sources.

Now we want to view or edit these Files in another App. I learned that it‘s not possible to share Files from your AppData Location (Sandbox) – you must copy the Files from APP Data to USER Data – per ex. Documents Location. I create a app specific working directory at DocumentsLocation.

Attention: I‘m not checking if Permissions are set – this isn‘t the goal of this App. To access Files at DocumentLocation you have to set WRITE_EXTERNAL_STORAGE.

<uses-permission android:name=”android.permission.WRITE_EXTERNAL_STORAGE” />

Using Files from DocumentsLocation sounds easy but makes things more complicated. We don‘t want to leave those Files at DocumentsLocation when sharing the File finished. Then we must delete them. And if the User edited the File we must know if the File was changed and saved or canceled. If the File was modified we must replace the origin File inside our AppData before deleting the File from DocumentsLocation.

Also after sending the File as a Stream per ex. to a Printer we must delete the copied File as soon as printing was done.

The workflows are different for Android and iOS.

Android needs

  • FilePath URI
  • MimeType

to find matching Apps.

iOS needs

  • FilePath as NSURL

On iOS there‘s no way to limit the Apps for View or Edit capabilities.

Android does an in-place-Editing of the File, where iOS copies the File over to the other App. To get the modified File back a second manual step is required by the user.


The interesting question now is „HowTo know when sharing is finished and if Edit mode was canceled or saved“ ?

Android gives us the startActivityForResult() to get a Result Code back.

Unfortunately I didn‘t found a way to get this Result Code back from the Java Code in

Using Java code on the other side is much easier to read and write as JNI code.

There‘s a workaround: as soon as the Intent Activity is started, our Qt App changes ApplicationState to Suspended and when the Intent Activity closes, the ApplicationState goes back to Active. You can watch the ApplicationState to know when sharing was finished and you also can compare modified Timestamp of the File to recognize changes from Edit mode.

This workflow is marked ‚A‘ in the Overview at the beginning of this article.

More coding, but much more flexible is to use JNI to construct the complete Intent Activity and to go with QAndroidActivityResultReceiver To get the Result back.

Here‘s the method to construct the Edit Intent:

    QAndroidJniObject jniPath = QAndroidJniObject::fromString("file://"+filePath);
    if(!jniPath.isValid()) {
        emit shareError(requestId, tr("Share: an Error occured\nFilePath not valid"));
    // next step: convert filePath Java String into Java Uri
    QAndroidJniObject jniUri = QAndroidJniObject::callStaticObjectMethod("android/net/Uri", "parse", "(Ljava/lang/String;)Landroid/net/Uri;", jniPath.object());
    if(!jniUri.isValid()) {
        emit shareError(requestId, tr("Share: an Error occured\nURI not valid"));
    // create a Java String for the ACTION
    QAndroidJniObject jniParam = QAndroidJniObject::getStaticObjectField("android/content/Intent", "ACTION_EDIT");
    if(!jniParam.isValid()) {
        emit shareError(requestId, tr("Share: an Error occured"));
    // then create the Intent Object for this Action
    QAndroidJniObject jniIntent("android/content/Intent","(Ljava/lang/String;)V",jniParam.object());
    if(!jniIntent.isValid()) {
        emit shareError(requestId, tr("Share: an Error occured"));
    if(mimeType.isEmpty()) {
        emit shareError(requestId, tr("Share: an Error occured\nMimeType is empty"));
    // create a Java String for the File Type (Mime Type)
    QAndroidJniObject jniType = QAndroidJniObject::fromString(mimeType);
    if(!jniType.isValid()) {
        emit shareError(requestId, tr("Share: an Error occured\nMimeType not valid"));
    // set Data (the URI) and Type (MimeType)
    QAndroidJniObject jniResult = jniIntent.callObjectMethod("setDataAndType", "(Landroid/net/Uri;Ljava/lang/String;)Landroid/content/Intent;", jniUri.object(), jniType.object());
    if(!jniResult.isValid()) {
        emit shareError(requestId, tr("Share: an Error occured"));
    QAndroidJniObject activity = QtAndroid::androidActivity();
    QAndroidJniObject packageManager = activity.callObjectMethod("getPackageManager",
    QAndroidJniObject componentName = jniIntent.callObjectMethod("resolveActivity",
    if (!componentName.isValid()) {
        emit shareNoAppAvailable(requestId);
    // now all is ready to start the Activity:
    // we have the JNI Object, know the requestId
    // and want the Result back into 'this' handleActivityResult(...)
    QtAndroid::startActivity(jniIntent, requestId, this);

Thanks to QAndroidActivityResultReceiver we‘ll get the Result back into:

void AndroidShareUtils::handleActivityResult(int receiverRequestCode, int resultCode, const QAndroidJniObject &data)
    // we're getting RESULT_OK only if edit is done
    if(resultCode == RESULT_OK) {
        emit shareEditDone(receiverRequestCode);
    } else if(resultCode == RESULT_CANCELED) {
        emit shareFinished(receiverRequestCode);
    } else {
        emit shareError(receiverRequestCode, tr("Share: an Error occured"));

Now it‘s easy to connect to the SIGNAL (shareEditDone, shareFinished, shareError) from QML.This workflow is marked as ‚B‘ in the Overview above.

Please note: the JNI code is different for VIEW/EDIT and SEND – please take a look at all the details in the sources.

Was not so easy to figure out all the details but now it‘s really easy for you: just copy the code into your app ��

On iOS we‘re using a UIDocumentInteractionController:

    NSString* nsFilePath = filePath.toNSString();
    NSURL *nsFileUrl = [NSURL fileURLWithPath:nsFilePath];
    static DocViewController* docViewController = nil;
        [docViewController removeFromParentViewController];
        [docViewController release];
    UIDocumentInteractionController* documentInteractionController = nil;
    documentInteractionController = [UIDocumentInteractionController interactionControllerWithURL:nsFileUrl];
    UIViewController* qtUIViewController = [[[[UIApplication sharedApplication]windows] firstObject]rootViewController];
        docViewController = [[DocViewController alloc] init];
        docViewController.requestId = requestId;
        // we need this to be able to execute handleDocumentPreviewDone() method,
        // when preview was finished
        docViewController.mIosShareUtils = this;
        [qtUIViewController addChildViewController:docViewController];
        documentInteractionController.delegate = docViewController;
        [documentInteractionController presentPreviewAnimated:YES];

Know when Preview is done from DocViewController:

(void)documentInteractionControllerDidEndPreview:(UIDocumentInteractionController *)controller
#pragma unused (controller)
    [self removeFromParentViewController];

We detect the end of preview and call documentPreviewDone() in IosShareUtils:

void IosShareUtils::handleDocumentPreviewDone(const int &requestId)
    emit shareFinished(requestId);

Now from QML we can connect to the SIGNAL and know when sharing was done.

The good thing: the workflow now is similar for Android and iOS and easier to handle from common QML code.

Please take a look at .pro – there are some Android and iOS specific sections. Also dont forget to add AndroidExtras.

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

Some Screenshots

Open in… Dialog on Android. Select the App you want to use for View or Edit mode:


Edit the Image and cancel or save:


ACTION_SEND enables you to print Text, Images or PDF Files.

Choose the Printer Plugin:


Then select your Printer, configure the Printer and print:


On iOS the UIDocumentInteractionController gives you a preview of the File and provides the iOS Share Button at bottom left:


The Share Button presents the available Apps:


Conclusion: you can share Files on Android and iOS and integrate into your specific workflows. SIGNALS are mitted to let you know what the User has done.

There‘s even a call to check if for a given MimeType and Action Type any matching Apps are available on Android.

Call this check before downloading a File from Cloud, to provide a better UX: instead of downloading and then telling users that there‘s no App available you can inform in advance.

One question is open for now: HowTo suppress the Preview on iOS and only show what you get from clicking on the Share Button. Thanks to any tips from Qt / Obj-C experts.

I‘ll continue work on this app and add some more Intent Actions for Android.Also will add functionality to open the App from outside by providing a File URI or MimeType.

Now have fun!

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

November 30, 2017

Elisa is a music player designed to be simple and nice to use.

Elisa project has now an official mailing list hosted by kde (Elisa mailing list). Alexander Stippich is now a regular KDE developer and we felt a list was good to coordinate work on Elisa. I am also very happy, to nine years after I joined KDE, to have the honor to recommend somebody. I still remember how excited I was at that time.

Following blog post from Kevin Funk on binary-factory service (KDE binary factory), Elisa windows installers are regularly built. Thanks a lot to the KDE windows contributors. They do a lot of work to help projects like mine.

2017-11-30 14_28_43-Snapshot of Elisa on Windows 10

The following things have been integrated in Elisa git repository:

  • Fix the case of albums with same title but different cover images by Matthieu Gallien ;
  • Do not duplicate albums when a track is missing album artist metadata by Matthieu Gallien ;
  • Hopefully fix compilation for neon distribution by Matthieu Gallien ;
  • By default tracks are from disc 1 now: fix some tracks being from disc 0 by Matthieu Gallien ;
  • Fix play list save and restore when exiting and launching the application by Matthieu Gallien ;
  • Rename default license file to match documentation on community KDE wiki by Matthieu Gallien ;
  • Add a reference to a snapshot for Elisa appstream metadata by Matthieu Gallien ;
  • Rename Qml import to org.kde.elisa by Matthieu Gallien ;
  • Give credit to astippich by Matthieu Gallien ;
  • Lower requirement for frameworks except for kdoctools. This is needed to built on by Matthieu Gallien ;
  • Print a warning if KFileMEtaData version is older than 5.39.0 that can crash when used the way Elisa code is using it by Matthieu Gallien ;
  • Add a test for MediaPlayList persistence by Matthieu Gallien ;
  • Make text vertically aligned to center for NavigationActionBar by Alexander Stippich ;
  • Alexander Stippich changed icons in playlist entry such that :
    • Playing indicator and remove button now share the position. indicator becomes invisible when entry is hovered or selected ;
    • Play button is transformed into a play pause button, allowing pause in the playlist entry. this is also a nice way to indicate the playing status when hovered or selected ;
  • Add automatic tests for MediaPlayList by Matthieu Gallien ;
  • Remove extra rowsInserted signals in MediaPlayList when adding tracks from an artist by Matthieu Gallien ;
  • When reselecting e.g. the all albums view with the view selector, the stackview shows a previously opened album. Reset to the initial item when the view selector is used by Alexander Stippich ;
  • Add a test for tracks removal via TracksListener and fix some bugs by Matthieu Gallien ;
  • Fix XML in copyright text for about dialog by Alexander Potashev ;
  • Allow to display all albums from an artist directly from the view of one of its albums by Matthieu Gallien ;
  • Do not extract i18n messages from localFileConfiguration/ to elisa.pot by Alexander Potashev.

The KDE community has spoken and it has chosen the proposals which will define the general direction of the KDE project over the next three or four years.

How does the KDE community decide where it wants to take the project? Well, every once in a while, we hold a Request for Proposals, if you will. All members of the community are encouraged to submit their grand ideas which will lay out long-term targets. Proposals are voted on democratically, again, by the community. This ensures it is truly the community that guides the KDE project to wherever the community wants it to go.

This year, the three most voted proposals have been:

Top-notch Usability and Productivity for Basic Software

Nate Graham proposes improving the usability of KDE's software and making it more accessible and user-friendly for a wider variety of users. Nate argues that, although KDE apps and environments in general boast a "long list of features that are genuinely useful for normal people's typical use cases", small but noticeable inconsistencies and niggling usability issues sometimes mar KDE's semblance of maturity with casual users.

Nate reasons that focusing on irksome details of the most common and commonly used of KDE's software, such as Plasma, Dolphin, Okular and Discover, would be the first step towards polishing the whole. He mentions, for example, the annoying bug that makes Plasma require the Wifi password twice; or enhancements that can be made to Dolphin to support column view or colourised files and directories, like MacOS X's file browser sports; or improving Okular's stamp feature to make it suitable for digitally signing documents.

KDE's environments and applications are mature and usable to a great extent, but by getting small incremental improvements, we can nearly subliminally improve the overall feel of the project and increase its uptake with the general public.

Privacy Software

In synch with KDE's vision, Sebastian Kugler says that "KDE is in a unique position to offer users a complete software environment that helps them to protect their privacy". Being in that position, Sebastian explains, KDE as a FLOSS community is morally obliged to do its utmost to provide the most privacy-protecting environment for users.

KDE will bring privacy to all
your devices, including your

This is especially true since KDE has been developing not only for desktop devices, but also for mobile - an area where the respect for users' privacy is nearly non-existent. Sebastian thinks that the intrusion on users’ personal lives is very dangerous. Users can have their livelihood and even personal safety put at risk when their confidential data makes its way into the hands of unscrupulous companies or hostile government agencies.

To make sure KDE environment and apps protect users’ privacy, Sebastian lists several measures that developers can implement. He proposes that applications not expose private data by default, asking the user for explicit consent before sending data to third parties. Other measures would involve apps using privacy-protecting protocols when communicating with the outside world; say, a widget should use Tor to collect weather information. Applications should also only require the bare minimum user information to operate and only when it is essential.

Finally, the proposal explains that KDE must provide the right tools to further safeguard users' privacy. These tools include email clients that offer easy ways of encrypting messages, privacy-protecting chat and instant messaging protocols and clients, and support for online services that can be implemented on personal servers.

Streamlined Onboarding of New Contributors

Getting more people involved with the project
is crucial for the survival of KDE.
Photo CC By-SA by Teia

Although we have made many improvements to KDE's development infrastructure and tools over the years, there are still several things we can do to streamline the access for contributors, says Neofytos Kolokotronis. Thinking of ways to get more people involved in the development, Neofytos proposes measures to simplify newcomer participation within KDE.

KDE is a living community and, as such, it is threatened if new users do not become contributors and therefore do not join its ranks, bringing in new blood and fresh ideas. To solve this potential problem, Neofytos wants the community to look at methods of incrementing user involvement. This will require analysing the available resources, especially the people and time that they can invest in this effort.

He also proposes KDE improve and standardise protocols for accepting and mentoring new users, as well as correcting issues with documentation and tools used to receive new contributions, such as KDE's bug tracking system.

The KDE community will start implementing the proposals into concrete actions and policies. The proposals will shape how the KDE community creates software and works with its members, as well as with outside users. In view of the winning ideas, we can expect a more polished KDE experience, enhanced privacy protection and a more accessible and welcoming community for years to come.

To make sure all KDE's goals are met, we need your support. Head over to the End of Year fundraiser (coming soon!) and help us meet our yearly funding target. You can contribute to the success of KDE and we will also show appreciation with karma and gifts!

November 29, 2017

This Saturday ( December 2nd ) the second Kubuntu Kafe Live, our online video cafe will be taking place from 21:00 UTC.
Join the Kubuntu development community, and guests as our intrepid hosts.

  • Aaron Honeycut
  • Ovidiu-Florin Bogdan
  • Rick Timmis

Discuss a cornucopia of topics in this free format, magazine style show.

This show includes Technical Design and Planning for a Kubuntu CI Rebuild, a Live Testing workshop in the Kubuntu Dojo, Kubuntu product development and more.

We will be attempting to run a live stream into our YouTube Channel although we encourage you to come and join us in our Big Blue Button conference server, use your name and welcome to join room 1 and come and interact with us and be part of the show.

See you there

Cutelyst the Qt Web framework got a new release, this is likely to be the last of the year and will be one of lasts releases of the 1.x.x series. I’d like to add HTTP/2 support before branching 1.x.x and having master as 2.0 but I’m not yet sure I’ll do that yet.

For the next year I’d like to have Cutelyst 2 packaged on most distros soon due Ubuntu’s LTS being released in April, and H2 might delay this or I delay it since it can be done using a front-end server like Nginx.

The 1.11.0 version includes three new plugins written by Matthias Fehring, a Memcached plugin that simplifies talking to a memcached server, a memcached based session store, that stores session information on the memcached server, and a static compressed plugin to serve compressed versions of static files.

Besides that I extended the EngineRequest class to serve as a base class for Engine’s requests allowing to get rid of some ugly casts and void pointers that carry the real request/connection. This doesn’t affect user code as long as they don’t implement their own engine.

Setting a Json reply is now a bit simpler now that two overloads directly accepting QJsonObject and QJsonArray were added.

Cutelyst license preamble on files was fixed to state it’s LGPLv2.1+, and finally pkg-config is now fully supported.

Go get/break/package/.* it!

November 28, 2017

by Banksyby Banksy
At Akademy 2016, the KDE community started a long-term project to invigorate its development (both, technically and organizationally) with more focus. This process of soul-searching has already yielded some very useful results, the most important one so far being agreement of a common community-wide vision:

A world in which everyone has control over their digital life and enjoys freedom and privacy.

This presents a very high-level vision, so a logical follow-up question has been how this influences KDE’s activities and actions in practice. KDE, being a fairly loose community with many separate sub-communities and products, is not an easy target to align to a common goal. A common goal may have very different on each of KDE’s products, for an email and groupware client, that may be very straight-forward (e.g. support high-end crypto, work very well with privacy-respecting and/or self-hosted services), for others, it may be mostly irrelevant (a natural painting app such as Krita simply doesn’t have a lot of privacy exposure), yet for a product such as Plasma, the implications may be fundamental and varied.
So in the pursuit of the common ground and a common goal, we had to concentrate on what unites us. There’s of course Software Freedom, but that is somewhat vague as well, and also it’s already entrenched in KDE’s DNA. It’s not a very useful goal since it doesn’t give us something to strive for, but something we maintain anyway. A “good goal” has to be more specific, yet it should have a clear connection to Free Software, since that is probably the single most important thing that unites us. Almost two years ago, I posed that privacy is Free Software’s new milestone, trying to set a new goal post for us to head for. Now the point where these streams join has come, and KDE has chosen privacy as one of its primary goals for the next 3 to 4 years. The full proposal can be read here.
“In 5 years, KDE software enables and promotes privacy”

Privacy, being a vague concept, especially given the diversity in the KDE community needs some explanation, some operationalization to make it specific and to know how we can create software that enables privacy. There are three general focus areas we will concentrate on: Security, privacy-respecting defaults and offering the right tools in the first place.


Improving security means improving our processes to make it easier to spot and fix security problems and avoiding single points of failure in both software and development processes. This entails code review, quick turnaround times for security fixes.

Privacy-respecting defaults

Defaulting to encrypted connections where possible and storing sensible data in a secure way. The user should be able to expect the KDE software Does The Right Thing and protect his or her data in the best possible way. Surprises should be avoided as much as possible, and reasonable expectations should be met with best effort.

Offering the right tools

KDE prides itself for providing a very wide range of useful software. From a privacy point of view, some functions are more important than others, of course. We want to offer the tools that most users need in a way that allows them to lead their life privately, so the toolset needs to be comprehensive and cover as many needs as possible. The tools itself should make it easy and straight-forward to achieve privacy. Some examples:

  • An email client allowing encrypted communication
  • Chat and instant messenging with state-of-the art protocol security
  • Support for online services that can be operated as private instance, not depending on a 3rd party provider

Of course, this is only a small part, and the needs of our userbase varies wildly.

Onwards from here…

In the past, KDE software has come a long way in providing privacy tools, but the tool-set is neither comprehensive, nor is privacy its implications widely seen as critical to our success in this area. Setting privacy as a central goal for KDE means that we will put more focus on this topic and lead to improved tools that allow users to increase their level of privacy. Moreover, it will set an example for others to follow and hopefully increase standards across the whole software ecosystem. There is much work to do, and we’re excited to put our shoulder under it and work on it.


One of the interesting things about QML is that it leverages OOP property semantics of QObject to drive its declarative workflow.


We attach into any QObject the developer requests and monitor it (and optionally all it’s children).

To gather the information we need, we will collect information for every property and connect to the property’s notification signal to see when it changes.


This is the repository:

This allows us to see:

  • Spurious property change notifications
  • Property changing bursts (i.e. same property changing values repeatedly in a short amount of time)
  • How a change in a value can have an effect on other properties

At the moment we have two ways of inspecting an application:
On one hand we have warnings that allow us know specific things and even add breakpoints to the sore points. The warnings at the moment look like this:
repeated value ScrollView_QMLTYPE_43(0x5648c6d97b50) width QVariant(double, 320) 8 times
repeated value Kirigami::BasicTheme(0x5648c6986ac0) backgroundColor QVariant(QColor, QColor(ARGB 1, 0.988235, 0.988235, 0.988235)) 11 times

Additionally, we have a timeline view output from tracking. You can see an example of plasmashell run here.


An idea would be to integrate automatically ModelTest, so if a QAbstractItemModel is found, a ModelTest instance is attached that makes sure the model is true to its promises.

Another thing that bothers me is that we are forced to compile it into the application. If we could make it possible to have processes attached or start the application somewhat automatically (like GammaRay does, wink-wink) we would ease the adoption of these tools.

What do you think? Do you think it’s useful?
Feedback very welcome.

Linux perf is an immensely useful and powerful tool suite for profiling of C/C++ applications.
I have used it extensively and successfully on various customer projects, both for desktop applications as well as automotive or industrial projects targeting low-end embedded Linux targets running on ARM hardware.

The biggest problem with perf really is its usability, or lack thereof. Over the years I have tried my best in educating people on how to use the tool suite, both in form of conference talks as well as during KDABs Linux profiling trainings and workshops and, most recently, by creating hotspot.

Additionally, I have started contributing upstream to the Linux kernel repository to alleviate some of the problems. A short time ago, one important patch series of mine got merged and will be part of Linux 4.15, which drastically improves Linux perf usability when dealing with common C++ workloads.

The patch series completely reworked the representation and handling of inlined frames in perf report.

Up until recently, inlined frames were not shown at all in the report. This made the interpretation of reports from C++ applications very hard, since the compiler will inline a lot of templates.

continue reading

The post Update to Linux perf report appeared first on KDAB.

KDAB has unique experience in porting the code base for toolkits like Qt 3, Qt 4, Motif, Java, Tcl, GTK, .NET, MFC, and Photon to Qt 5. Porting legacy GUI toolkits to Qt 5 is a job where proven experience saves a lot of time.

In this presentation we highlight the main problems facing developers using legacy toolkits, what migrations are and which approaches to migrations are possible. We give you a short overview of common guidelines in starting migrations including common pitfalls and also discuss how KDAB can assist in porting your legacy code base to a modern Qt-based system using our tooling for automatic conversions.

View the slides.

For detailed information on migration, read our whitepaper: Modernizing Legacy Systems continue reading

The post Porting Applications to Qt appeared first on KDAB.

November 27, 2017

Since Akademy in Almería we have been going through the process of defining goals for KDE for the next 3 to 4 years. Different ideas were proposed and refined. 10 of them made it into the community-wide vote to select 3 of them. Today I am proud to announce the result based on the 684 submitted votes.

The 3 goals KDE will be focusing on over the next 3 to 4 years are:

  • Top-notch usability and productivity for basic software: We want our users to love our software and enable them to do their day-to-day work hassle-free. As part of this goal we will focus on polishing our basic software so everyone will be delighted to use it. For more details see the proposal.
  • Privacy Software: A central part of KDE’s vision for the future is privacy. As part of this goal we will work on improving privacy-related features, settings and applications all over KDE’s software. Once done KDE software enables and promotes privacy, which is crucial for a free and open society and protecting our users from harm. For more details see the proposal.
  • Streamlined onboarding of new contributors: KDE can only achieve its vision if we enable many people to join our community and support us with their specific knowledge and skills – be it programming, artwork, promotion, translation, event organizing or any of the other hundreds of areas needed to make KDE successful. As part of this goal we will identify and remove barriers to entry in our documentation, infrastructure and processes. For more details see the proposal.

I am excited about what this will bring for the next years of KDE and how it will help bring great software to our users.

What will happen next? I am helping the proposers of the goals come up with a plan. There will be sprints related to the topics in 2018 as well as a progress report at Akademy. None of these goals is going to be achieved without help. It’ll need all hands on deck – including yours! If you are able to help with one of them please add your name to the proposal on Phabricator linked above so you can be contacted once the plan for each of them becomes more clear.

Thanks to everyone who submitted one of the great proposal, Ben for providing the list of voters and Kevin for his help in making sense of the votes.

With all the turmoil the project experienced in 2017 it looked for a while as if we wouldn’t have a face to face meeting this year. But that’s not good for a project working on its fourth major release! We knew we really had to sit together, and finally managed to have a smaller than usual, but very productive, sprint in Deventer, the Netherlands from Thursday 23th to Sunday 26th.

Not having been together since August 2016, we had an agenda stuffed with a enormous backlog of items. And since we’ve been working on new code for a long time ago, our bug tracker was also slowly dying from elephantiasis of the database.

Let’s do the bug tracker first: we managed to close over 120 bugs! Not every bug that gets closed gets closed with a fix: the problem is that most bug reports are actually help requests from users, and many of the rest are duplicates, or requests for features that are irrelevant for Krita. Still, while triaging the list of open and unconfirmed bug reports, we managed to fix more than a dozen real bugs.

Here’s the proof:

Now let’s go to the other topics that were discussed

Krita 4.0

We finalized the set of features that we want to complete for 4.0, and came up with a schedule. Originally, we wanted to release 4.0 this year, but that’s completely impossible…

We still want to add:

  • Lazy brush for easy line art colorization (mostly works, needs some testing and bug fixing)
  • Stacked brushes, redux. Our first implementation was ready in 2016, but we discarded it and will have to redo the work in a different way
  • The new text tool. This is going to be a massive simplication of our original plans… While Boudewijn is still working on making vertical text work in Qt, that’s not going to be ready. The tool itself will be simple, easy to use for the main use-cases for Krita.
  • There are some missing bits in features that are mostly done, like the Python plugin manager, or finishing up the brush editor redesign.

We are also still facing some problems on some platforms: on Linux, we don’t have a working script to package Python and GStreamer in the appimages, and the way we package G’Mic is wrong. On OSX, we don’t have a working G’Mic at all, and no support for PDF import. We do need help with that!

The current release schedule looks like this:

  • 31st December: Freeze. No new strings, no new features accepted
  • January 3rd: first Beta 1 test builds
  • January 10th: Krita 4.0 Beta 1
  • From now on, weekly development builds, if we have the resources to automate that.
  • From now on, bug fixing, bug fixing, bug fixing.
  • March 7th: first Krita 4.0 release candidate
  • March 14th: Krita 4.0

Right now, the focus is on releasing Krita 4.0, which means that currently no new Krita 3.3.x bug fix releases are planned, even though there are plenty of fixes that can be backported and should be released.

HDR Support

We’ve been approached about supporting HDR screens in Krita, which is different from the existing 10 bits/channel screens that Krita has supported on some systems for a long time. But even though we can get access to the hardware, we don’t have the time to work on it, and the API’s seem to be exclusively Windows-only.

Get Hot New Stuff

This was a 2017 Google Summer of Code project. We had an almost working implementation, but something changed server-side which means that right now nothing works. It turns out to be pretty hard to figure out what’s up, and that means it’s unlikely Krita 4.0 with have a dialog for download resources from

Python API

Over the summer, we have gained a lot of experience with our Python API, also thanks to our Google Summer of Code student Eliakin. We found some places where the current API needs to be expanded and decided to do just that…

Google Summer of Code

Krita has participated in all editions of Google Summer of Code, and many of the current developers cut their teeth on Krita’s codebase during GSOC. We discussed how we could improve our participation, and how we could attract the kind of students who stay around after the project ends. One problem there is the new rules, which specify that a student can participate only twice. In our experience, it is much better for retention if students can participate during their entire university career.

We also decided to raise the bar a bit. We often see candidates who fulfill the current requirement of three patches with three one-liner patches. We’ll create a set of tasks that have a rating (1 to 3), and only candidates who have reached at least 6 points of completed tasks will be acceptable. We will also test the candidates on their ability to navigate the codebase by asking them to make a diagram of a particular subsystem.


The telemetry Summer of Code project has resulted in working code and a working server, but was not far enough to be mergeable to Krita. We are still interested in learning what we can about the way Krita is actually used, though. The student is interested in doing his bacherlor’s thesis on this subject, too.

Contributor Guide

Currently, information about contributing to Krita is scattered all over our website, our manual, the KDE community wiki, the source code repository and external websites. Jouni has created an outline for a contributor manual that should be part of our manual website. We’ve even already started on some parts, like the bug tracker howto!

Could you tell us something about yourself?

Hello, I’m Radian. I’m a digital artist from Russia. Honestly, I don’t know what else to say here ��

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

I’m not working professionally yet but I’m aiming for it! I want to find work in-house because that will speed up my progress, but there is like only one serious company in my city.

What genre(s) do you work in?

I like to make neat atmospheric illustrations, usually it’s fantasy inspired works. Actually, I care more about making it look cool so I can paint whatever I like. Except cityscapes and street views. I hate those.

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

I think I can name two – Mike Azevedo and Craig Mullins. I like Mike’s colors and light work so much, he definitely knows how to make it awesome. He was one of the artists who inspired me a lot from the start of my art journey.
Craig – digital art pioneer who managed to keep progressing and experimenting for so many years. I’d say I like his “philosophy”, his way to do things, his way to think.

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

About 3 years ago, I tried to make a drawing with vector tools and mouse ��

What makes you choose digital over traditional painting?

Colors, all of them! It’s easy to mess with, easy to experiment. I like good traditional art, I like its aesthetics, but I don’t like working with traditional media, mixing colors, cleaning brushes and such.

How did you find out about Krita?

From a comment on some entertainment site. It was something like “hey, there is also Krita, it can do the same things as SAI and even more, plus it’s free”.

What was your first impression?

“Whoa, so many buttons! I’m gonna press them all”

What do you love about Krita?

Someone can say that they like blending brushes or a lot of tools or something else. But I’ll say Krita is extremely comfy. It’s very logical (in most areas �� and it has many little but very handy things.

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

There are some things that slightly annoy me but those are either very hard to fix or super small and not even worth ranting about. Sometimes both. Improvements? I’m sort of an idea guy so I can write a kilometer-long text about what can be improved. Though I can’t say anything needs to be improved in Krita. Vectors and text tools aren’t good but they’re already in development.

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

The best balance between comfort and functionality. There are a few cool Photoshop things that I’d like to have in Krita but if I start Photoshop I
can count a lot of things there that I’d like to get from Krita. It’s just hard to use for me. Any other program I tried could win one or two rounds, but Krita always had more. More functions, more tricks for artists, more little handy things and more possibilities. Also I think Python scripting will add a new level of comfort that will never be defeated.

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

I tend to hate any of my artwork if it is more than 1-3 months old but there are a couple of exceptions. The Kiki painting I made for the artbook “Made with Krita” is one of them. I used a bunch of new tricks in here and probably made a few good choices by accident.

What techniques and brushes did you use in it?

I used my own brush pack, many brushes “inspired” by some Photoshop brushpack from pro artists. There was’t a single brush that satisfied me so I had to learn brush creation magic ��

As I said, I like Mullins’s philosophy: more looking, more thinking, less painting. I usually trying to do as much as I can with as few strokes as I can. But I like to experiment as well. If there are so many techniques, why should I use only one? Try everything, break all rules! Learn from mistakes and especially learn from successful experiments.

Where can people see more of your work?

Anything else you’d like to share?

It’s kinda funny to see how such a small team makes such big progress in development while Photoshop stagnates for years with a big company full of professionals.

Thanks for all your work guys, keep it up!

A month ago my family and I left our home to go to a new country and city for a month. As an experiment. As a source of variation. As something new. As an adventure.

The background to going to Berlin is that we’re starting a new office in Berlin and people need to be onboarded (we are also looking for people in Gothenburg). This requires someone on the ground. At the same time, we, as a family, have been playing with the idea to relocated for a longer or shorter period and the timing of this opportunity was nice, as the length of the trip was short enough to be manageable.

The move led to a lot of changes. We went from a city of 40000 inhabitants to Berlin with around four million. We moved from a house of 200 square meters to a two room apartment of around 50 square meters. We also moved from two working adults with kids attending school, to four weeks of home schooling and one parent taking care of the home.

From a work perspective, it has been fun to get to know a group of new colleagues from all over the world. From that perspective, Berlin is very un-german. Everyone seems happy to speak English and you always encounter people from various background. Still, I got some proper german practice, so I now master explaining that my german is bad :-)

From a family perspective, things have been better than I ever expected. The benefit of a big city is that there are a million things to do. The feeling is more that we are running out of time, rather than that we want to go back home again. Also, the sheer selection of playgrounds in Berlin is really great. We have three good playgrounds within 2-3 blocks from our apartment, so plenty of variation.

Another family related issue is the ease of commuting. I went from a 45 minutes train ride to a 3-4 minutes walk, which gives me a lot more time to spend with my family. At the same time, it does take away 90 minutes everyday of concentrated mail management, which means that my inbox currently is in a very sad state.

Another aspect in the same direction is that we spend a lot more time together as a family, partly since the kids don’t run off to their friends right after school. This also means that I get a lot less free time for taking care of hobbies such as foss-north and foss-gbg.

As you can tell, most aspects of this temporary change are double-edged. If I were to move anywhere permanently, some of this would have to be resolved. At the same time, I got a month of working in Germany combined with way more time with my kids and wife than I usually get, so I would not want to change anything. I think that this picture really sums things up. Berlin is a city of contrasts and compared to my life in Sweden, the way I lived in Berlin had a strong contrast as well.

November 26, 2017

For the last couple of years my focus was on the Osmocom project to bring Free Software to the world of telecommunication. With a group of enthusiasts we have implemented the components necessary to run a complete network using Free Software. The Rhizomatica project is using the software to connecting people that were left behind. Our tools enabled high impact security research leading, leading to improvements to privacy and security for all of us….

But during the last months I had the opportunity to return to C++ and Qt work and it feels like coming home to the world of ARM powered hardware. When I left, the transition from consumer electronics (e.g. settop boxes) to automative (e.g. IVI) began and it seems it successfully completed! On Friday I explored a regression in OpenSSL and today I had the pleasure to understand input method handling of wayland a little bit better.

I wanted to see if I can use wayland and run QtVirtualKeyboard only in the Compositor. I couldn’t find answers in the documentation and started to read the code. Once I understood how it should work, I found a simple example in QtWayland. Isn’t Qt wonderful?

As I have gone down the rabbit hole let me try to share some of my reading. At the core is the unstable (API subject to change) text-input protocol. Upstream of wayland-protocols is still at v1 of the protocol but QtWayland includes a copy of v2 and has rather complete support for the compositor and client (thanks KDAB!).


To make it work the compositor needs to signal support for the “zwp_text_input_manager_v2” interface. In QML/Quick this needs to be done by adding the following inside the WaylandCompositor component:

TextInputManager {

This will instantiate a QWaylandTextInputManager and call ::initialize on it. Then auto-generated code will use wl_global_create to register the interface in the global registry. Clients will request a text_input and the manager will create one or use a QWaylandTextInput and then send events down to the client. E.g. if there is a soft keyboard set a breakpoint in QWaylandTextInput::sendKeyEvent in the compositor and see from where it is coming and how it will send the event to a client.


Once the client starts the QWaylandIntegration will create a QWaylandDisplay and then query/initialize the registry. The answer will call QWaylandDisplay::registry_global for every registered interface. For the the zwp_text_input_manager_v2 interface the integration will initialize a QtWayland::zwp_text_input_manager_v2 and for each input device a QtWaylandClient::QWaylandTextInput (different namespace) will be created.


Now Compositor and Client will communicate through the wayland connection (no dbus). With Qt APIs the client will notice which element has been focused and will request the input method to be shown (QtWaylandClient::QWaylandInputContext::showInputPanel) and the Compositor  will forward this to the QInputMethod (see QWaylandTextInputPrivate::zwp_text_input_v2_show_input_panel)

Putting it together

In the end this is rather simple.. create a TextInputManager, use the InputPanel of the QtVirtualKeyboard and start your compositor with QT_IM_MODULE=qtvirtualkeyboard. Done!


Helloooo =D I don't know if you remember, that on the beginning of this year I went o a Google event where I learn a few about Progressive Web Apps, if you don't, please access this post, where I explain my adventure. So today I went to an another Google Event, Google Dev Fest Rio(GDGRio), … Continue reading Update on PWAPlanet – Planet KDE

November 25, 2017


Qt 3D has a flexible and extensible architecture that allows us to easily add our own new functionality to it without disrupting the existing features.
The functionality of Qt 3D is divided among so-called aspects, each of which encapsulates a particular subject domain such as rendering, input, or animation.

This short series of articles will walk you through the process of adding a new aspect that provides component types and behaviour for a new domain not covered by Qt 3D out of the box. For this example we have chosen to implement an aspect that allows calculating running means of the frame rate. Of course this could legitimately be added to the renderer, but it's simple enough that it makes a nice example for our purposes today. The full source code for the example is available for download.


The application that we will build looks like this. It's a very simple Qt 3D scene and the window shows the current mean frame rate.

Custom Aspect Screenshot

There are a few parts that we need to consider when adding such new functionality (see the diagram):

  • Aspect — Responsible for orchestrating any jobs that need executing each frame and for managing the storage of any backend objects.
  • Components — Provided by your library/application are what an Entity will aggregate to give it new behaviour. The components are the main API you will need to create.
  • Nodes — Just as for components except that subclasses of QNode typically provide supporting data required by a component.
    For example QAnimationClipLoader is a node that provides animation key frame data to a QClipAnimator component.
  • Backend Nodes — The backend counterparts to any frontend components or nodes provided by your library/application. These are the objects typically processed by jobs running on the threadpool as dictated by the aspect itself.
  • Mapper — Custom mappers are registered with the aspect and are responsible for creating, fetching, and destroying backend nodes on demand. The mapper is used by QAbstractAspect and QAspectEngine to synchronise lifetimes of the frontend and backend objects.
  • Jobs — Created and scheduled by the aspect and which process the backend nodes. Jobs may also send events to the frontend nodes and components if properties change.
  • Change Arbiter — Responsible for delivering events between and among the frontend and backend objects. No need to do anything with this but be aware of its existence.

Adding the Aspect

Writing the initial aspect itself is really trivial. Just subclass QAbstractAspect and register it with the QAspectEngine:

[sourcecode lang="cpp" title="customaspect.h"]
class CustomAspect : public Qt3DCore::QAbstractAspect
explicit CustomAspect(QObject *parent = nullptr)
: Qt3DCore::QAbstractAspect(parent)

QVector<Qt3DCore::QAspectJobPtr> jobsToExecute(qint64 time) override
qDebug() << Q_FUNC_INFO << "Frame time =" << time;
return {};

[sourcecode lang="cpp" highlight="6" title="main.cpp"]
int main(int argc, char **argv)
QGuiApplication app(argc, argv);
Qt3DExtras::Quick::Qt3DQuickWindow view;

view.engine()->aspectEngine()->registerAspect(new CustomAspect);

return app.exec();

QAbstractAspect has a few more virtuals that you can override to do initialisation and cleanup should you need them. However, for this simple example all we need to do is to implement the jobsToExecute() virtual. Later we will use this to schedule a job to execute on the threadpool each frame, but for now we just output some debug text to return an empty vector (no jobs to run). Note that these virtual functions will only be called once you have registered the aspect with the QAspectEngine (see above) so that it is part of the simulation. We will return and complete the aspect a little later.

The FpsMonitor Component

We wish to add functionality to report on the mean frame rate averaged over a given number of frames. With this is mind we might come up with an API something like this:

[sourcecode lang="cpp" title="fpsmonitor.h"]
class FpsMonitor : public Qt3DCore::QComponent
Q_PROPERTY(int rollingMeanFrameCount READ rollingMeanFrameCount WRITE setRollingMeanFrameCount NOTIFY rollingMeanFrameCountChanged)
Q_PROPERTY(float framesPerSecond READ framesPerSecond NOTIFY framesPerSecondChanged)

explicit FpsMonitor(Qt3DCore::QNode *parent = nullptr);

float framesPerSecond() const;
int rollingMeanFrameCount() const;

public slots:
void setRollingMeanFrameCount(int rollingMeanFrameCount);

void framesPerSecondChanged(float framesPerSecond);
void rollingMeanFrameCountChanged(int rollingMeanFrameCount);

float m_framesPerSecond;
int m_rollingMeanFrameCount;

Note that we use a declarative, property-based API so that this class can easily be used from QML as well as from C++. The property rollingMeanFrameCount is a regular read-write property and the implementation of the setter and getter functions are completely standard. This property will be used to control the number of frames over which we calculate the moving average frame rate. The framesPerSecond property is a read-only property which will later be set from a job that we will write to process FpsMonitor components on the Qt 3D threadpool.

Creating a Small Test Application

Before we can utilise our custom component from QML, we must register the type with the QML type system. This is a simple one-liner that we can add to our main function:

[sourcecode lang="cpp" title="main.cpp"]
qmlRegisterType<FpsMonitor>("CustomModule", 1, 0, "FpsMonitor");
rootContext->setContextProperty("_window", &view);

where we also took the opportunity to export the window to the QML context too (we'll need that in a moment).

Once that is done, we can import the CustomModule QML module and make use of the FpsMonitor component just as we would for any of the built in types.

[sourcecode lang="js" title="main.qml"]
Entity {
components: [
FpsMonitor {
rollingMeanFrameCount: 20
onFramesPerSecondChanged: {
var fpsString = parseFloat(Math.round(framesPerSecond * 100) / 100).toFixed(2);
_window.title = "CustomAspect: FPS = " + fpsString
+ " (" + rollingMeanFrameCount + " frame average)"

Of course at this point, the FpsMonitor doesn't do much except for setting the value of the rollingMeanFrameCount property. Once we complete the backend, the above code will update the window title to show the current mean frame rate and the number of frames used to calculate it.

In the next part we will implement the corresponding backend node for FpsMonitor and make sure it gets created and destroyed on demand and set up communications between the frontend and backend.

continue reading

The post Writing a Custom Qt 3D Aspect – part 1 appeared first on KDAB.

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.