November 23, 2017

It has been over a week now that I attended Grace Hopper Celebration India 2017 in Bangalore from 16-17 November, yet the excitement still flows in me! I attended GHCI 2017 as a KDE Developer and student attendee. Big thanks to KDE Community for funding me!

The Grace Hopper Celebration India (GHCI) is the largest and most influential event for women pursuing technical careers in computing and technology in the country. The conference was held at Bangalore International Exhibition Centre(BIEC), a premier exhibition center in Bangalore. The place was vibrant and energetic with close to 2000+ attendees.

The conference began early morning around 7:30 with registrations. There was a warm welcome and a presentation session followed by keynote session by Pankajam Sridevi, MD at ANZ Bengaluru. Even on the second day, the event started early and there was a keynote by Dr. Rebecca Parsons, CTO at ThoughtWorks. Both the days, the event continued till evening till 5 pm with many interesting tracks based on Big Data, Artificial Intelligence, Open Source, Machine Learning and several speed-mentoring sessions.

In the lower hall, “Career Fair” was ongoing event was both the days, attracting more than 1000+ students and professionals. Around 50 top tech companies set up their booth at the event. People seeking internship/job could easily talk to software engineers and recruiting team members. Each booth also had ongoing events and they distributed lots of amazing goodies!

The networking and the lunch/hi-teas were amazing!

I interacted with many other student attendees and company professionals and exchanged information about my experience with KDE community and Google Summer of Code projects for 2 years. I was almost amazed by their interest in knowing about it more. I got this golden opportunity to guide several open source enthusiasts towards applying for GSoC and contributing under KDE.

The conference totally changed my mind about women and tech. In those 2 days, I got a chance to see and interact with a lot of women who have turned stones in their tech career, while balancing their personal life. GHCI has definitely inspired me so much and taught me, “Where there is a will, there is a way!”

A sincere gratitude to KDE Community for funding my entire visit and making it possible for me to be a part of largest tech conference for women in the country! I would also like to thank Anita Borg Institute for this wonderful event. Every girl should attend this event and experience the journey at least once in their lifetime! ��



We’ve known for several years that our multi-touch support in Qt Quick has been inadequate for many use cases.  We have PinchArea, to handle two-finger scaling, rotation and dragging; and MultiPointTouchArea, which can at least be used to show some sort of interactive feedback for the touchpoints, or maybe you could write a little state machine in JavaScript to recognize some kind of gesture.  As for the rest of Qt Quick though, the main problems are 1) support for mouse events came first; 2) Qt assumes there is only one mouse (the “core pointer”); 3) QMouseEvent and QTouchEvent (and a few more) have no suitable intermediate base class, so they end up being delivered independently; 4) that being hard, shortcuts were taken early on, to treat touch events as mouse events and deliver them the same way.  So the result is that you cannot interact with two MouseAreas or Flickables at the same time, for example.  This means you cannot press two Buttons at the same time, or drag two Sliders at the same time, if they are implemented with MouseArea.

At first I hoped to fix that by making MouseArea and Flickable both handle touch events separately.  The patches to do that were quite complex, adding a lot of duplicated logic for the full parallel delivery path: a QMouseEvent would take one path and a QTouchEvent would take another, in the hope that the interaction would work as much the same as possible.  It was months of work, and at the end it mostly worked… but it was hard to keep all the existing autotests passing, and colleagues worried about it being a behavior change.  MouseArea proclaims by its name that it handles mouse events, so as soon as it begins to handle touch events separately, it becomes a misnomer.  Suddenly you would be able to press two Buttons or Tabs or Radio Buttons at the same time, in applications and sets of controls which weren’t designed for it.  (So we tried adding a bool property to opt in, but needing to set that in every MouseArea would be ugly.)  MouseArea and Flickable also need to cooperate a lot, so the changes would have to be done together to keep everything working.  It was possible, but narrowly missed shipping in Qt 5.5 due to uncertainty.

So eventually we took a different route, after we found a reasonable combination of ideas that had been proposed.

One idea was that since we cannot refactor the QEvent hierarchy (yet) due to the binary compatibility mandate, we could instead create wrapper classes which make the events look like we want them to, complete with properties for the benefit of QML, and deliver those instead, using a mostly-unified event delivery path in QQuickWindow and QQuickItem.

Another idea was the realization that dynamically creating and destroying these wrapper events is silly: instead we use a pool of instances, as we have been doing in other cases where an “event” object is emitted by a signal (for example the object emitted by MouseArea.positionChanged is always the same instance, since Qt 5.8).  With that optimization, wrapping one event with another is no longer a big performance hit.

Another idea was suggested: maybe it would be nice if handling an event from a pointing device were as easy as using the Keys attached property: for example, Mouse.onClicked: { ... } or PointingDevice.onTapped: { ... } But soon after came the realization that there can be only one instance of an attached property per Item to which it is attached.  One of the problems with MouseArea is that it tries to do too much, so it didn’t make sense to simply re-implement all the functionality in a monolithic MouseAttached.  We wanted the ability to handle a click or a tap without caring which device it comes from, for example, because that’s what every Button control needs to do.  It’s the same with any gesture that can be performed with either the mouse or a single finger.  Perhaps there could be one attached property per gesture rather than one per device type, then?

Since QML is a declarative language, it’s nice to be able to declare constraints rather than writing if/else statements in JavaScript signal callbacks.  If an object which handles events is designed not to care which device a gesture comes from, there will nevertheless be cases when your application does care: you want to perform a different action depending on whether it is tapped on the touchscreen or clicked with the right mouse button, or you want to do something different if the control key is held down while dragging an object.  By allowing multiple instances of these handler objects, we can declare the constraints on them by setting properties.  It should be OK to have as many instances as you like.  Each instance should be lightweight so that you don’t fear to have too many instances.  The implementation should be in C++, and it should be simple and understandable.  Each handler should do one, or at most a few very closely-related things, and do them well.

Those concerns have taken us away from the idea of using attached properties, for now.  What we have instead is a new family of classes in Qt Quick: Pointer Handlers.

A Pointer Handler is a type of object which you can declare inside any Item, which handles events from pointing devices on behalf of that Item.  You can declare as many of them as you need: typically, one per interaction scenario.  All the common constraints that we could think of are declarable: you can make the handler react only if it’s a touch event, only to certain mouse buttons, only if the correct number of fingers are pressed within the bounds of the Item, only if a particular modifier key is held, etc.

Draggin’ balls

Common gestures are represented by their own handler types.  For example, if you declare

Rectangle {
    width: 50; height: 50; color: "green"
    DragHandler { }

then you have a Rectangle which can be dragged around the scene via either mouse or touch, without writing any Javascript, and without even needing to bind the handler to its parent in any way.  It has a target property, and the default is the same as its parent.  (But by setting the target to a different Item, you can capture events within one item, but manipulate the other.)

Of course, if you have two of those green rectangles with DragHandlers in them, you can drag them both at the same time with different fingers.

Every Pointer Handler is a QObject, but it’s not a QQuickItem, and it doesn’t have too many of its own variables, so each instance is about as small as a practical QObject subclass can be.

Every single-point handler has the point property, to expose all the details about the touchpoint or mouse point that we can find. There are properties for pressure and ellipseDiameters: some devices may have force sensors, while others may measure the size of the contact patch (but many devices don’t provide either). It has a velocity property which is guaranteed to be defined: we calculate and average the velocity over the last few movements for a slightly smoother reaction. Having the velocity available could potentially enable velocity-sensitive gestures: perhaps a flick should be done at a certain minimum speed. (Is that the right way to distinguish a flick from a drag? It hasn’t been easy to make that distinction before.) Or, if you have the velocity at the time of release, a drag gesture can end with momentum: the object keeps moving a short distance in the same direction. This makes your UI feel more alive. So far we have not formalized MomentumAnimation into a supported animation type, but there is a pure-QML prototype of it in tests/manual/pointer/content/MomentumAnimation.qml.

two red balls being dragged simultaneously with DragHandler

Tap dancing

TapHandler handles all the press-and-release gestures: single quick taps or clicks, double-taps, some other number of taps, holding it pressed for a configurable period of time, or holding it for various periods of time, all in unique ways. (When you touch a touchscreen, it often doesn’t make any sound, but you can tap a mouse button; so we thought “tap” is a more future-proof name for this gesture than “click”.)  You can show feedback proportional to how long it has been held (an expanding circle, progress bar or something like that).

TapHandler detecting a triple-tap and then a long press

Pinch me if this is for real

There is a PinchHandler.  If you declare it inside an Item, you will be able to scale, rotate and drag that Item using the pinch gesture.  You can zoom into any part of the Item that you like (an improvement on PinchArea).  It can handle larger numbers of fingers, too: you can declare PinchHandler { minimumTouchPoints: 3 } to require a 3-finger pinch gesture.  All the transformations then occur relative to the center point between the three fingers, and the scaling is relative to the average increase or decrease in spread between them.  The idea came from the way that some versions of Ubuntu use the 3-finger pinch for window management: apparently they thought the content in the window may have some use for a 2-finger gesture, but most applications don’t use 3 fingers for anything, so it’s OK to reserve the 3-finger pinch to scale and move windows around the desktop.  Now since you can write a Wayland compositor in QML, you can easily recreate this experience.

zooming into a map with PinchHandler

Getting to the points

Finally, there is PointHandler.  Unlike the others, it doesn’t manipulate its target Item: it exists only to expose the point property.  It’s similar to an individual TouchPoint in MultiPointTouchArea, and can be used for the same purpose: to provide interactive feedback as touchpoints and the mouse cursor move around the scene.  Unlike MultiPointTouchArea, it does not exclusively grab the touchpoints or the mouse, so having this interactive feedback does not prevent interacting with other handlers in other Items at the same time.  In the animations on this page, it’s used to get the finger sprites to follow my fingers around.

Are we there yet?

So now I’ll get to the reasons why this stuff is in Tech Preview in 5.10.  One reason is that it’s incomplete: we are still missing support for mouse hovering, the mouse wheel, and tablet stylus devices (a stylus is still treated as a mouse for now).  None of the handlers have velocity-sensitive behavior.  We can imagine a few more Handlers that could be written.  There should be public C++ API so that you can create your own, too.  Handlers and Flickable are getting along somewhat, but Flickable is a complex monolithic Item, and we think maybe it can be refactored later on.  There is a FakeFlickable manual test which shows how it’s possible to re-create a lot of its functionality in QML with two ordinary Items, plus a DragHandler and a few animations.

FakeFlickable: a componentized Flickable

Another reason is the naming.  “Pointer Handlers” sounds OK in isolation, but there is pre-existing terminology which makes it confusing: a pointer might be a variable which points to a memory location (but that’s not what we mean here), and a handler might be a sort of callback function that you write in JavaScript.  If you write TapHandler { onActiveChanged: ... } do you then say that your handler has a handler?  We could start using the word “callback” instead, but it’s an anachronism in some circles, and in QML our habits are hard to change now.

Another reason is that QtLocation has some complex use cases which we want to use as a case study, to prove that it’s possible to navigate a map (and any interactive content upon it) with small amounts of readable code.

Perhaps I’ll continue this later with another post about another way of doing gesture recognition, and how that might affect how we think about Pointer Handlers in the future.  I haven’t explained the passive grab concept yet.  There’s also more to be defined about how to build components which internally use Pointer Handlers, but give the application author freedom to override behavior when necessary.

So to wrap up for now, Pointer Handlers are in Tech Preview in 5.10.  We hope you will play with them a lot.  Especially if you have some old frustrations about interaction scenarios that weren’t possible before.  Even more so if you ever wanted to create a touch-intensive UI (maybe even multi-user?) without writing a C++ event-forwarding and QObject-event-filtering mess.  We need to start getting feedback from everyone with unique use cases while we still have the freedom to make big changes if necessary to make it easy for you.

So far the usage examples are mostly in tests/manual/pointer.

Since it’s in tech preview, the implementation will continue to be refined during the 5.10 series, so follow along on the 5.10 git branch to keep up with the latest features and bug fixes.

The post Say hello to Qt Quick Pointer Handlers appeared first on Qt Blog.

This blog post takes a brief look at some of the new features in Qt Quick Controls 2.3 released as part of Qt 5.10. See also New Features in Qt 5.10 for a more detailed list.

New styles

We are introducing two new styles: Fusion and Imagine. The Fusion style looks familiar to those who have been using Qt Widgets. This is a QML-based implementation of the same design.

The Fusion style

The Fusion style

The Imagine style is based on configurable image assets, giving designers full control over how the style looks like. The style comes with a default set of image assets that have been exported from Sketch.

The Imagine style

The Imagine style

With the Imagine style it is possible to style the controls without a single line of code. There will be also examples for Illustrator and Photoshop. These designs are provided as starting points for those creating their own designs. See Qt Quick Controls 2: Imagine Style from Mitch for more details.

Menus and actions

Menus and friends have taken big steps forward. We have added new QML types called MenuBar, Action and ActionGroup, and Menu has gained support for sub-menus. It is now possible nest menus, as expected on desktop platforms. We also added support for mnemonics in menus and buttons.

MenuBar and cascading Menus

MenuBar and cascading Menus

The usage is identical to the earlier generation of Qt Quick Controls:

import QtQuick 2.10
import QtQuick.Controls 2.3

ApplicationWindow {
    id: window
    width: 500
    height: 400
    visible: true

    menuBar: MenuBar {
        Menu {
            title: qsTr("&File")
            Action { text: qsTr("&New...") }
            Action { text: qsTr("&Open...") }
            Action { text: qsTr("&Save") }
            Action { text: qsTr("Save &As...") }
            MenuSeparator { }
            Action { text: qsTr("&Quit") }
        Menu {
            title: qsTr("&Edit")
            Action { text: qsTr("Cu&t") }
            Action { text: qsTr("&Copy") }
            Action { text: qsTr("&Paste") }
            MenuSeparator { }
            Menu {
                title: qsTr("&Find/Replace")
                Action { text: qsTr("Find &Next") }
                Action { text: qsTr("Find &Previous") }
                Action { text: qsTr("&Replace...") }
        Menu {
            title: qsTr("&Help")
            Action { text: qsTr("&About") }

These are important steps bringing Qt Quick Controls 2 menus functionality-wise on par with native platform menus. This makes it feasible to start considering the next steps integrating native platform menus as a backend for Qt Quick Controls 2 menus.


We have added support for configurable palettes, currently supported by the Default, Fusion, and Imagine styles. The other styles are coming later. Here’s a screenshot of the Default style with a custom dark palette:

The Default style with a custom dark palette

The Default style with a custom dark palette

Q & A:

What about TableView?
– We have made great progress with a new TableView based on the same Qt Quick item view framework ListView and GridView are based on. The current implementation is already able to manage a two-dimensional set of visible items for the current viewport. The performance is on the same level with ListView and GridView. Large amount of columns does not kill the performance like in the ListView-based TableView in Qt Quick Controls 1. Stay tuned for a blog post on the subject.

When is the famous “Object destroyed during incubation” problem going to be fixed?
– We believe we have now the necessary ingredients for finally tackling this issue. I have prepared a patch to the QML engine that allows us to defer the execution of the built-in delegates so that a) replacing them with custom delegates at construction time won’t cause troubles for asynchronous incubation and b) the performance (in terms of construction time) of a customized control is not affected by the built-in delegates. As soon as the necessary patch to the QML engine has landed, we can start making use of it in Qt Quick Controls 2. We are targeting the 5.9.x LTS series. I’ll report status updates to QTBUG-50992.

The post Are you ready for Qt Quick Controls 2.3? appeared first on Qt Blog.

Warm white lightsWarm white lights
Since I’ve been playing with various home automation technologies for some time already, I thought I’d also start writing about it. Be prepared for some blogs about smart lighting, smart home and related technologies.

Most recently, I’ve gotten myself a few items from IKEA new product range of smartlight. It’s called trådfri (Swedish for wireless). These lights can be remote-controlled using a smartphone app or other kinds of switches. These products are still fairly young, so I thought I’d give them a try. Overall. the system seems well thought-through and feels fairly high-end. I didn’t notice any major annoyances.

First Impressions

Trådfri hub and dimmerTrådfri hub and dimmer

My first impressions are actually pretty good. Initially, I bought a hub which is used to control the lights centrally. This hub is required to be able to use the smartphone app or update the firmware of any component (more on that later!). If you just want to use one of the switches or dimmers that come separately, you won’t need the hub.
Setting everything up is straight-forward, the documentation is fine and no special skills are needed to install these smartlights. Unpacking unfortunately means the usual fight with blister packaging (will it ever stop?), but after that, a few handy surprises awaited me. What I liked:
Hub hides cablesHub hides cables

  • The light is nice and warm. The GU10 bulbs i got give 400 lumens and are dimmable. For my taste, they could be a bit darker at the lower end of the scale, but overall, the light feels comfy warm and not too cold, but not too yellow either. The GU10 bulbs I got are spec’ed at 2700 Kelvin. No visible flickering either.
  • Trådfri components are relatively inexpensive. A hub, dimmer and 4 warm-white GU10 bulbs set me back about 75€. It is way cheaper than comparable smartlights, for example Philips Hue. As needs are fairly individual exact prices are best looked up on IKEA’s website by yourself.
  • The hub has a handy cable storage function, you can roll up excessive cable inside the hub — a godsend if you want to have the slightest chance of preventing a spaghetti situation.
  • The hub is USB-powered, 1A power supply suffices, so you may be able to plug it into the USB port of some other device, or share a power supply.
  • The dimmer can be removed from the cradle. The cradle can be stuck on any flat surface, it doesn’t need additional cabling, and you can easily take out the dimmer and carry it around.
  • The wireless technology used is ZigBee, which is a standard thing and also used by other smarthome technologies, most notably, Philips Hue. I already own (and love) some Philips Hue lights, so in theory I should be able to pair up the Trådfri lights with my already existing Hue lights. (This is a big thing for me, I don’t want to have different lighting networks around in my house, but rather concert the whole lighting centrally.)

Pairing IKEA Trådfri with Philips Hue

Let’s call this “work in progress”, meaning, I haven’t yet been able to pair a Trådfri bulb with my Hue system. I’ll dig some more into it, and I’m pretty sure I’ll make it work at some point. If you’re interested in combining Hue and Trådfri bulbs, I’ll suffice with a couple of pointers:

If you want to try this yourself, make sure you get the most recent lights from the store (the clerk was helpful to me and knowledgable, good advice there!). You’ll also likely need a hub at least for updating the firmware. If you’re just planning to use the bulbs together with a Hue system, you won’t need the hub later on, so that may seem like 30€ down the drain. Bit of a bummer, but depending on how many lights you’ll be buying, given the difference in price between IKEA and Philips, it may well be worth it.

\edit: After a few more tries, the bulb is now paired to the Philips Hue system. More testing will ensue, and I’ll either update this post, or write a new one.

If you want to develop for Plasma Mobile, but you don’t have a Mobile device, it is useful to emulate a Plasma Mobile on your desktop or laptop. Earlier this was not documented and has been asked multiple times on how to achieve this.

This blog post is intended to help install a Plasma Mobile on the qemu-x86.

  • First of all create a qemu-image of 10GB size.
qemu-img create -f raw neon-unstable.img 10G
  • Download the KDE Neon Dev edition (git unstable) ISO. Link
  • Start the qemu system with the downloaded the KDE Neon ISO.
qemu-system-x86_64 -cdrom /path/to/neon-devedition-gitunstable-current.iso -boot menu=on -drive file=/path/to/created/neon-unstable.img,format=raw -vga virtio -display sdl,gl=on -m 2G -enable-kvm

KDE Neon startup

  • This will boot the KDE Neon system with Plasma Desktop. You will need to use Calameras to install the Plasma on the virtual machine.

KDE Neon Installation

  • Once installed, shutdown the virtual machine and restart the machine without ISO attached.
qemu-system-x86_64 -boot menu=on -drive file=/path/to/created/neon-unstable.img,format=raw -vga virtio -display sdl,gl=on -m 2G -enable-kvm
  • In the virtual machine, open konsole and add the repository for Plasma Mobile.
curl | sudo apt-key add -
sudo add-apt-repository
  • Install the updates
sudo apt update && sudo apt upgrade

KDE Neon install updates

  • Install the Plasma Phone shell and configuration for Plasma Phone.
apt install plasma-phone-components plasma-phone-settings
  • Logout from the Desktop Session and select the Plasma Mobile (Wayland) session.

SDDM Plasma Mobile

  • This steps will start Plasma Mobile session.

Plasma Mobile in qemu

Please note that this steps are experimental at the moment, I am working on providing pre-built ISO images which will not require the KDE Neon developer edition ISO.

Back in April we wrote about image-based styling for Qt Quick Controls 2. Since then, we have made good progress and nailed down some aspects that were still under consideration. We call the new style “Imagine”.

The style works by scanning a directory of images and applying those images to the controls. For example, when a Button is created, the style will look for button-background.9.png (or button-background.png for non-resizable buttons). As an example of what that image could look like, here’s button-background.9.png from the default assets:

Imagine Style Button background image.

When the user presses the button, the style then looks for button-background-pressed.9.png (or button-background-pressed.png). In the case of the default assets, that would look like this:

Imagine Style pressed Button background image.

The .9.png extension represents 9-Patch images. Using this format, we’re able to encode information about how the control should look when it is resized into the image itself. Combine this with the pre-defined file naming convention and you’ve got a style that can be customized without ever touching QML, giving designers complete control over what they do best, and allowing developers to focus on writing applications, not styles.

To provide a starting point for creating your own style, we’ve created a complete asset template in Sketch:

Default Imagine style Sketch template

Default Imagine style Sketch template (Sketch)

For those who prefer Illustrator or Photoshop, we’ve provided smaller templates, each with their own example that uses the assets:

Qt Quick Controls 2 - Imagine Style Example: Automotive

Qt Quick Controls 2 – Imagine Style Example: Automotive (AI)

Qt Quick Controls 2 - Imagine Style Example: Music Player

Qt Quick Controls 2 – Imagine Style Example: Music Player (PSD)

The Imagine style is available with Qt 5.10. For more information, see the documentation.

The post Qt Quick Controls 2: Imagine Style appeared first on Qt Blog.

November 22, 2017

Vuelve la sección de los pequeño trucos para optimizar nuestro trabajo con el escritorio Plasma. En esta ocasión quisiera explicar cómo utilizar ssh en Dolphin, es decir, como acceder de forma gráfica a carpetas de otros sistemas mediante el protocolo ssh y poder así tener un control más visual de éste.

Cómo utilizar ssh en Dolphin

Mientras termino de perfilar un artículo sobre mi sistema multimedia hogareño y sigo aprendiendo cositas para mejorar su uso, voy descubriendo métodos de trabajo que me hacen la vida más fácil.

Una de ellas es poder controlar mi Rapsberry Pi del Salón de forma remota utilizando mi ultrabook o cualquier PC que esté en mi red local. Para ello puedo utilizar el protocolo Samba pero quería ir un poco más allà y utilizar el protocolo ssh.

Cómo conectar Raspberry Pi con Dolphin

Evidentemente, lo primero que hice fue buscar por internet la forma de hacerlo y rápidamente me di cuenta que necesitaba un par de datos antes de empezar: la dirección ip de la raspeberry pi en mi red local y el nombre de usuario y contraseña de la misma Raspeberry.

El primer dato lo debes sacar de tu red pero será parecida a 192.169.x.x., el segundo suele ser pi como nombre de usuario y raspberry como password.

Antes de seguir con el método de conexión debo advertir que debemos asegurarnos que tenemos activado en servidor ssh en la raspberry y el paquete openssh-server en la máquina que se conecta.

En mi caso, desde mi portátil con KDE Neon, que no es más que un Ubuntu 16.04, simplemente debo escribir esto en la consola:

$ sudo apt install openssh-server

Con estos datos ya podía seguir las instrucciones de la red, que consistían siempre en “Escribe esto en la barra de direcciones de Dolphin: fish://pi@192.168.x.x/home/pi/”. Lo cual es correcto y que funciona a la perfección, como podemos ver en la imagen inferior.

Cómo utilizar ssh en Dolphin

La única pega, en mi humilde opinión, es que si no carga demasiado el sistema, todas las opciones de protocolos de conectividad deberías estar listos para utilizar a la primera. No obstante, tampoco debería quejarme tanto ya que si todo fuera perfecto ¿para qué serviría KDE Blog?



We are happy to announce the release of Qt Creator 4.5 RC!

We think that we are pretty close to what we want to release as Qt Creator 4.5.0, so please take this opportunity to give us final feedback through the bug tracker, our mailing list, or on IRC (#qt-creator on For information about the new features and improvements in this version, please have a look at the beta blog post or our change log.

Get Qt Creator 4.5 RC

The opensource version is available on the Qt download page, and you find commercially licensed packages on the Qt Account Portal. Qt Creator 4.5 RC is also available under Preview > Qt Creator 4.5.0-rc1 in the online installer (as an update to the beta). Please post issues in our bug tracker. You can also find us on IRC on #qt-creator on, and on the Qt Creator mailing list.

The post Qt Creator 4.5 RC released appeared first on Qt Blog.

I am pleased to inform that Qt 5.9.3 is released today. As a patch release Qt 5.9.3 does not add any new functionality, focus is in bug fixes and performance improvements.

Compared to Qt 5.9.2, the new Qt 5.9.3 contains over 100 bug fixes and in total more than 500 changes since Qt 5.9.2. For details of the most important changes, please check the Change files of Qt 5.9.3.

Qt 5.9.3 release also contains the latest security fixes, including fixes to the two vulnerabilities in Qt for Android port.

Our intention is to make frequent patch releases for Qt 5.9 LTS. Qt 5.9.4, planned for January 2018, will bring the the next set of bug fixes from Qt 5.9 branch.

If you are using the online installer, Qt 5.9.3 can be updated to using the maintenance tool. Offline packages are available for commercial users in the Qt Account portal and at the Download page for open-source users.

The post Qt 5.9.3 Released appeared first on Qt Blog.

Two vulnerabilities have been identified in Qt for Android which could be used by a malicious application to hijack an existing Qt for Android application on the same device. The vulnerabilities in question were found by JPCERT Coordination Center, and have been assigned the following vulnerability IDs: JVN#27342829 and JVN#67389262.

These vulnerabilities have subsequently been fixed in Qt 5.9 as well as the Qt 5.6 branch of Qt. Qt 5.9.3, which was released today, contains all required patches.

For users of Qt 5.7 or Qt 5.8, we have prepared patch sets which can be applied to the source tree in order to fix these issues. They can be downloaded from Qt Account or by accessing these links: 5.6.3, 5.7.1 and 5.8.0. The patches are organized in qtbase/ and qttools/ subfolders for the code repositories where changes are needed.

Thanks to Bogdan Vatra from KDAB for supplying the necessary patches on short notice.

The post Security advisory about Qt for Android appeared first on Qt Blog.

November 21, 2017

Un año más se va a celebrar Season of KDE 2018, una nueva edición de un programa cuyo objetivo es incorporar nuevos estudiantes al gran proyecto mundial que es KDE. A lo largo de los nueve años anteriores Season of KDE se ha consolidado como una alternativa bastante fiable a otros programas como Google Summer of Code o Google Code In.

Season of KDE 2018 busca mentores y estudiantes

Season of KDE 2015

2 estudiantes presentando sus proyectos en Akademy 2015 de A Coruña

Uno de los objetivos del proyecto KDE es involucrar al mayor número de personas en él y para ello organiza todo tipo de acciones: eventos como Akademy, encuentros como los Sprints, blogs colaborativos como KDE Planet, participación en proyectos para estudiantes como el Google Code In o Google Summer of Code.

No contento con esto, una vez al año organiza Season of KDE, es decir, su programa para involucrar a nuevos estudiantes en KDE. Una especie de Google Summer of Code pero para colaborar directamente en KDE y con la posibilidad de desarrollar proyectos no vinculados necesariamente con la programación, es decir, proyectos de promoción, documentación, diseño, etc.


Season of KDE 2018Además, del anuncio oficial de lanzamiento del Dot de KDE ( Boudhayan Gupta) os dejo una especie de preguntas y respuestas sobre el proyecto, que seguro que te estás haciendo como:

  • ¿Qué es Season of KDE? Bueno, eso ya lo he explicado.
  • ¿Quién puede formar parte? Todo el mundo que quiera.
  • ¿Qué gano con ello? Aparte de colaborar con el proyecto KDE, el proyecto más puntuado ganará un viaje a Akademy 2018 de Viena, con los gastos pagados. Además de una interesante línea en tu currículo.
  • ¿Cuánto tiempo tengo? El plazo máximo para inscribirse tanto mentores como para estudiantes es del 1 al 26 de diciembre
  • ¿Cómo empiezo? Busca un mentor y propón tu idea.

En fin, una buena forma de poner tu granito de arena en el proyecto KDE.

The talk by Jean-Baptiste Mardelle’s at Akademy 2017 is released along with many other interesting talks.

Akademy is the annual world summit of KDE, one of the largest Free Software communities in the world. It is a free, non-commercial event organized by the KDE Community.

You can find the slides here.

November 20, 2017

Slimbook es un compañía valenciana joven y dinámica que no ha cesado de mejorar sus productos en aras de ofrecer lo mejor a sus potenciales clientes. Es por ello que me complace compartir con vosotros el lanzamiento de Excalibur 2, la actualización de su modelo de 15 pulgadas de Slimbook que destaca por ser un calidad, ligereza y potencia. Y todo ello compatible con el mundo GNU y Linux al 100%.

Excalibur 2, Slimbook actualiza su ultrabook de 15

El pasado mes de abril, los chicos y chicas de Slimbook nos sorprendieron con Ultrabook de 15 pulgadas que bautizaron con el nombre de Excalibur. Su llegada fue bienvenida por la Comunidad Linuxera ya que cubría un hueco del mercado que tenía poca oferta.

Apenas seis meses más tarde, la compañía valenciana lanza Excalibur 2, una actualización de este modelo que mejora su potencia. De esta forma, este nuevo Excalibur 2 ofrece:

  • Procesadores Intel de 7ª generación (anteriormente de 6ª)
  • Memoria DDR4 a 2133 Mhz  (antes DDR3 a 1600Mhz)
  • Tarjeta gráfica NVIDIA GeForce 940 MX (antes
  • Pantalla de  15 pulgadas
  • Tteclado numérico
  • Chasis 100% de aluminio
  • Touchpad “Synaptics”
  • Dos huecos para disco duro: uno principal (normalmente un sssd) y otro auxiliar (mecánico o ssd) del tipo SATA 3 y formato de 2,5 pulgadas.

Todo a partir de un precio ajustado a las prestaciones que ofrece, unos 919 € la versión Intel i5.

Excalibur, el modelo de 15 pulgadas de Slimbook

Podéis ver el anuncio en el siguiente enlace.

¿Qué es un Slimbook?

Slimbook es una empresa afincada en Valencia que se dedica a montar equipos ultraportátiles de calidad con la posibilidad de que en su interior venga instalado de fábrica una distribución gnu/linux. Su idea es, como toda empresa, ganar dinero y pagar las nóminas de sus empleados pero no deja nunca de lado ni a sus clientes con un servicio técnico excelente ni a la Comunidad Linuxera, ya que no solo tiene un foro sino que uno de sus gerentes siempre está dispuesto a participar en podcast o en grupos de Telegram como el de KDE – Cañas y Bravas.

En la actualidad ofrecen varios ultraportátiles de 13.3 pulgadas (entre ellos un KDE Slimbook y un Slimbook Pro que es el que yo tengo), el modelo Excalibur de 15 cuya actualización he presentado hoy y el Slimbook One, un pequeño ordenador pero solo en tamaño,ya que sus capacidades y potencia está a la altura de casi cualquier ordenador de sobremesa.


November 19, 2017

Continuing the introduction of the new features coming soon with the next release of LabPlot (see the previous blogs here and here), we want to share today some news about the developments we did for the data fitting (linear and non-linear regression analysis) in the last couple of months.

Data fitting, one of the most common and frequently used data analysis tasks, got a lot of improvements. As already mentioned in the previous blog, all analysis functions benefited from the recent general UX improvements. Instead of going through the many manual steps, the final fit result can now be quickly produced via the context menu of the data spreadsheet or directly in the plot in the context menu of the data curve:

analyze and plot data context menu

Until now, the fit parameters could in principle take any values allowed by the fit model, which would lead to a reasonable description of the data. However, sometimes the realistic regions for the parameters are known in advance and it is desirable to set some mathematical constrains on them. LabPlot provides now the possibility to define lower and/or upper bounds for the fit parameters and to limit the internal fit algorithm to these regions only. Also, it is possible now to fix parameters to certain already known values:

New fit parameters widget

Some consistency checks were implemented to notify the user about wrong inputs (upper bound is smaller than the lower bound, start value is outside of the bounds, etc.) immediately.

The internal parser for the mathematical expressions learnt to recognize arbitrary user-defined parameters. With this, the fit parameters of custom models are automatically determined and there is no need for the user anymore to explicitly specify the parameter names manually once more when providing the start values and the constraints for them.

To obtain the improved parameter estimators for data where the error in the measurements is not constant across the different data points, fitting with weights is used usually as one of the methods to account for such unequal distributions of errors. Fitting with weights is supported in LabPlot now. Different weighting methods are available to ensure the appropriate level of influence of the different errors on the final estimation of the fit parameters. Furthermore, the errors for both, the x- and y-data points, can be accounted for.

The representation of the fit results was extended. In addition to what was already available in the previous release of LabPlot for the goodness of the fit, new criteria were added like t and p values, the probability that the null hypothesis in the t-test is true, confidence intervals, Akaike- and Bayesian information criteria. The screenshot below shows the current version of the fit dock widget:

New fit dock widget

Though quite a lot of features are already available in LabPlot in this area, many important and useful features like the support for different fitting algorithms, the subtractions of baseline from a spectrum, etc. need to be implemented. We hope to close the open gaps here very soon in one of the next releases.

This post is only a catch-up. In my opinion, I think that any project needs to have their social networks accounts and website so people can easily find information about it. To achieve that, the first thing that I put some work into, was on the website. Atelier isn't only for Linux users, so we [...]

Season of KDE encourages
everybody to help improve KDE.

KDE Student Programs is pleased to announce the 2018 Season of KDE for those who want to participate in mentored projects that enhance KDE in some way.

Every year since 2013, KDE Student Programs has been running Season of KDE as a program similar to, but not quite the same as Google Summer of Code, offering an opportunity to everyone (not just students) to participate in both code and non-code projects that benefits the KDE ecosystem. In the past few years, SoK participants have not only contributed new application features but have also developed the KDE Continuous Integration System, statistical reports for developers, a web framework, ported KDE Applications, created documentation and lots and lots of other work.

For this year’s Season of KDE, we are shaking things up a bit and making a host of changes to the program.


The 2018 Season of KDE will have more flexible schedule options for participants. They will now have the opportunity to choose between a shorter sprint project where the working period lasts 40 days or the usual full duration project with a working period of 80 days.

The timeline is:
1st - 26th December 2017: Participant and Mentor Application Period
30th December 2017: Projects Announced
1st January 2018, 00:00 UTC: Official SoK Work Period Begins
9th February 2018, 23:59 UTC: End of Work Period (40 day projects)
21st March 2018, 23:59 UTC: End of Work Period (80 day projects)
25th March 2018: Results Announced
31st March 2018: Certificates issued and sent out
Beginning of Q3 2018: Merchandise and Schwag sent out by courier


For the first time, we are now welcoming applications from teams of up to 2 people to participate in the same project. Teams may only participate in full 80-day projects. Shorter sprint projects are still only open to individual participants.

Cross-Organisation Projects

Do you want to see KDE software work well on other operating systems? Do you want KDE applications to integrate better with another desktop environment? Do you want to see applications from elsewhere integrate better with KDE?

In the 2018 Season of KDE, we are specially looking out for projects that can help integrate KDE better with other free software projects. We welcome mentors from other projects who’d like to help our participants in their efforts and encourage applications from participants who’d like to work on such a project. Participants will need to have a fairly reasonable grip on both KDE and the partner organisation’s projects, as well as a point of contact in the other organisation that can offer support throughout the duration of the project.

If you are from another FOSS Project, have a concrete idea of something SoK participants can implement and would like to mentor them for it, please get in touch with us directly.

A Grand Prize

The 2018 Season of KDE will accept a maximum of 6 projects. We will score each project based on objective criteria, and after completion of the project, the one with the highest score will win this year’s Season of KDE.

The participants from the winning project will have a chance to attend Akademy 2018, KDE’s annual world conference, which will be held in Vienna from August 11th - 17th, 2018. All travel and stay expenses will be paid for by KDE. At Akademy, you will have the chance to meet people from all around the world who make KDE possible, present your project to them, mingle with some of the brightest minds in the world of free software, and lose yourself in one of Europe’s historic centers of music and culture.

Getting Started

Prospective participants are advised to get in touch with us even before the application period begins to discuss possible projects. You can connect with us at #kde-soc on IRC, via our mailing lists, or contact the maintainer of an application you want to work on (or the specific team) directly.

If you’re looking for project ideas, you can find some on our Google Summer of Code 2018 Ideas Page. Prospective mentors are requested to add ideas to this page, so that we have a central repository of project ideas that may be used for both the 2018 Season of KDE and GSoC 2018.

Participants and mentors can apply here once applications open.

Dot Categories:

November 18, 2017

One of the features that were asked a lot of times on our Telegram groups was the ability to monitor the 3DPrinter via a stream feed. Since we released the beta version of the AtCore couple weeks ago, we are trying now to get more work done with Atelier. In our project, Atelier is the [...]

November 17, 2017

A View of Vienna.
Source: Bwag/CC-BY-SA-4.

Vienna Calling! This is not only a song by the famous Austrian singer Falco, but could also be the motto for next years Akademy.

In 2018 Akademy will be held at the University of Technology (TU Wien) in Vienna, Austria, from Saturday 11th to Friday 17th August.

The conference is expected to draw hundreds of attendees from the global KDE Community to discuss and plan the future of the Community and its technology. Many participants from the broad free and open source software community, local organizations and software companies will also attend.

Akademy 2018 is being organized with Fachschaft Informatik (FSINF). Apart from representing and counseling computer science students, FSINF engage in diverse political activities, such as FOSS activism, privacy and social justice, and so on.

Akademy 2018 Program

Akademy 2018 will start with a 2-day conference on Sat 11th of August and Sunday 12th of August, followed by 5 days of workshops, Birds of a Feather (BoF) and coding sessions.

Vienna and Akademy

Vienna, the capital of Austria, has around 1.8 million inhabitants. It is located in the middle of Central Europe, on the banks of the river Danube. With it's rich history that stretches back to Roman times. It was once the capital city of the Habsburg Empire ans is now a modern city, rated number one in diverse studies on quality of living.

TU Wien and Akademy

Almost all buildings of TU Wien are very close to the city center. From the venue a 10 minute walk will bring you directly to the inner city. Around 30,000 students study at Tu Wien, of which 6000 study Computer Science.

About Akademy

Akademy 2017, Almería.

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

Dot Categories:

For some time now the KDE community has had a separate Continuous Integration system running which repeatedly generates Windows installers and macOS app bundles (DMG) for a specific subset of KDE projects.

For a starter, all the KDevelop on Windows releases (read: 32-bit and 64-bit NSIS-based installers) are nowadays generated on this CI and the binary blob which falls out of this process is used as official Windows release installer on the KDevelop website.

So, what exactly does KDE's Binary Factory do, and how does it work -- and why was it created to begin with?


With the move to KF5 it became easier to get KDE applications running on non-Linux systems. With the very-much needed split of kdelibs into smaller components, it is now easier to pick & choose what to use on these platforms -- so arguably it is easier to cut out unwanted dependencies (think of DBus, KDE service daemons, ...) on these platforms and stop packaging them at all.

Still, the process of getting a reproducible build of KDE project X on either Microsoft Windows and/or macOS has always been a daunting task. Lots of energy went into KDE's Craft (an open source meta build system and package manager, primarily but not only focused on C++ projects) lately which also helped streamlining this process.

It has never been that easy to generate installers or app bundles for any KDE project (where Craft has a recipe for) using Craft. The missing bit was automating all this by using Craft on Continuous Integration system.

Introducing the KDE Binary Factory

KDE's Binary Factory is a Continuous Integration system primarily created for generating Microsoft Windows installers and macOS app bundles. It has no relation to KDE's CI system other than by sharing some of the machines of the CI workers. The jobs on the Binary Factory are mostly generated manually -- adding projects is very easy though.

How does it work?

First of all, the Binary Factory doesn't really know how to build a particular project. The logic for that -- i.e. which dependencies need to be there, which CMake arguments should be used etc. pp. -- is all stored only in Craft blueprints.

The Binary Factory has a set of projects for which Jenkins will trigger jobs on a nightly basis. It does not do much more than calling Craft like this each night:

# exemplary Windows job for kbruch

# rebuild kbruch
python "C:/Packaging/craftroot32/craft/bin/"  -v --fetch --unpack --compile --install --qmerge  kbruch

# after that, package kbruch (create a Windows installer)
python "C:/Packaging/craftroot32/craft/bin/"  -v  --package kbruch  

If there would be missing dependencies for kbruch, or dependencies out of date, Craft would automatically install or update the depedencies, resp.

After the package has been created, Jenkins is instructed to archive the result. You can easily grab the freshly generated installer on the job page, for instance: which usually shows something alike:

Last Successful Artifacts  
    kbruch-17.08.3-windows-msvc2017_32-cl.exe   32.65 MB    view

One click there and the download of the installer starts.

How do I add my pet project?

If you do want your project to be on the Binary Factory, add a recipe (documentation here) and then notify me.

I'd urge you to try building your pet project on Windows yourself first, via Craft, so we don't need to play ping-pong with the CI too much. You (the "project owner") are responsible that the Craft blueprint for your project is up-to-date and works.

Now what to do with the installer/bundle?

The Binary Factory generates Windows installers and macOS bundles at this point. Now what I would not like to see (what already happened) is that individual projects just link to the Binary Factory job pages and tell people 'here, this is the official release of project X'. You shouldn't just link to untested binaries.

Instead I'd like to establish this workflow for project owners:

If there's a release of, say, Kate:

  1. Project owner waits for or triggers a build of Kate on the Binary Factory
  2. Project owner verifies that the installer/bundle works(!)
  3. Project owner uploads the install/bundle on the KDE FTP into the correct project folder
  4. Project owner then adds links to the newly uploaded files on the FTP to the project homepage

Note: Of course linking to the Binary Factory to point users to 'nightly builds of project X' is of course fine -- we do that for KDevelop, too.

Why should I use the Binary Factory?

It has some nice benefits:

  • Automated nightly installer/bundle generation for your project, if set up properly
  • Automated signing of installers/bundles with a KDE-wide code signing certificate
    • Avoids false-positives in AV scanners, warnings by Windows SmartScreen, etc. pp.
  • No need to run a Windows or macOS CI yourself, for package generation
  • Kept up-to-date implicitly via Craft features
    • I.e. right now we're using Qt 5.9.1, KF5 5.37.0
  • It's all there already -- you just need to use it!

Future plans

Start generating macOS bundles

We have a macOS worker set up, but unfortunately the DMG package generation for macOS is still somewhat broken in Craft. We need to sit down and work on this. I don't think there's a lot work left; we can actually create macOS bundles just fine for KDevelop, but there are a few problems with missing shared libraries and/or wrongly set up library metadata (RPATH, etc.).

For the time being, the main focus is on providing Windows installers, but we'll have a look into providing macOS bundles soon-ish now.

Start releasing Windows installers

A couple of KDE projects would be really nice to have on Windows, and actually quite a few installers generated by the Binary Factory are already usable!

One prime example, Filelight:

Setting up a job on the Binary Factory for generating the installer for Filelight literally took me a few hours (for preparing the Craft blueprints, injecting the job in Jenkins -- that's it). Now we just need to link the installer on the official Filelight homepage.

Final words

I'm happy to see this finally working in an automated way. At least for the KDevelop team, the automated installer generation for the KDevelop installers has been a major step into the right direction. After a couple attempts of doing that on personal machines where we literally always managed to break our setup, we now have a clean, automated process of generating them on a isolated machine.

I hope the Binary Factory can be useful to other KDE projects as well. I'm happy to help you guys out to set up jobs on the CI so your personal projects can be built.

November 16, 2017

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

Alexander Stippich did several fixes in the interface while I focused on bugs related to the music database.

KDE community has been working on flatpak. For that, a runtime including Qt5 and KF5 frameworks has been written. Aleix Pol has written a recipe to build Elisa under flatpak. It is now built regularly from the git repository.

I am very enthusiastic about that since that should allow easy testing of the application thanks to the work of a lot of people on Flatpak and the support inside the KDE community.

Currently some features are not well working and some audio codecs are missing in the current runtime. Use it at your own risk and keep in mind that some parts are known not to work correctly. Please report any bugs or suggestions to the tracker.

In order to test, you can (extracted from the KDE community wiki) do the following steps:

I am afraid I have no snapshots to show today.

The following things have been integrated in Elisa git repository:

  • Fix context menu for MediaAllTrackView and MediaAlbumView by Alexander Stippich ;
  • Improvements of the single entry in the playlist by Alexander Stippich ;
  • Fixes in the play list for different albums with the same title ;
  • Fix mouse interaction and dragging while LabelWithTooltip is truncated by Alexander Stippich ;
  • Preliminary work to allow to store multiple artists for a track or an album ;
  • Report database errors and check for them during tests. I fail to see how to report such an error to an user (being a developer or a non technical user does not make any difference here) ;
  • Preliminary work to allow database versioning and evolution ;
  • Fix several bugs around the music database ;
  • Modify a bit the way tracks are tested for uniqueness ;

I am still planning to do an alpha release soon. This is an important milestone to test that everything needed to make a proper release after review will be possible.

November 15, 2017

Kubuntu Cafe Live, is our new community show. This new format show is styled using a magazine format. We created lots of space for community involvement, breaking the show into multiple segments, and we want to get you involved. We are looking for Presenters, Trainers, Writers and Hosts.

  • Are you looking for an opportunity to present your idea, or application ?
  • Would you like to teach our community about an aspect of Kubuntu, or KDE ?
  • Would you like to be a show, article or news writer ?
  • Interested in being a host on Kubuntu Cafe Live ?

Contact Rick Timmis or Valorie Zimmerman to get started

The Kubuntu Cafe features a very broad variety of show segments. These include free format unconference segments which can accommodate your ideas. Dojo for teaching and training, Community Feedback, Developers Update, News & Views.

For upcoming show schedule please check the kubuntu calendar

Check out the show to see the new format,


November 14, 2017

Following the previous blog posts related to the Qt WebGL plug-in development updates, we have some features to show.

As a quick recap: Qt WebGL QPA plug-in is a new platform plug-in which will allow your Qt Quick applications to be streamed and ran directly into the browser using streaming of OpenGL calls and rendered in the client using WebGL. For more info, check the related posts below.

After some months of bug-fixing and other improvements, we managed to accomplish some cool stuff. Take a look at one of our good old demos – Qt Cinematic Experience, running remotely on a TV Web Browser:

In the video, you can see the demo running remotely on the built-in web browser of a usual TV. For the interaction with the application, I’m using the ‘extremely fast’ TV remote which is interpreted as a mouse device. This shows that you can use the WebGL streaming plug-in if your application is targeting a smart-device with a browser to try your applications without creating and deploying the application, this can save a lot of development time.

Remember, you’ll be able to test the plug-in in the upcoming Qt 5.10 release. If you find any bug don’t hesitate to report it.

NOTE: If your application is using Text.NativeRendering and your text is not displayed properly, try removing this option.

The post Qt WebGL: Cinematic Experience appeared first on Qt Blog.

I've never really written much about my job since I've always done pretty mundane stuff. Yes, I always had really cool jobs (well, internships) except the one other full time job that I had - that I'd rather not talk about - but as far as the tech goes nothing was really out of the ordinary. That's changed, however, and the full extent of the coolness of my current job is starting to hit me so hard now I thought I just had to write about it.

Power Grids, Explained.

The world runs on electricity. Everything that you see around you runs on electricity - in some sense having power is almost as important as having drinking water. As it turns out though, if everyone generated their own electrical power according to their own needs, it would be massively inefficient. Power generation works on economies of scale, so it's much cheaper - and more efficient in a thermodynamic sense - to generate a massive amount of power in a specialised location and distribute that power using cabling to all the consumers.

So a nation's electricity infrastructure will consist of a couple of million households or offices or factories and stuff that consume power, a few hundred electricity generation sites, and a tangle of cables that carry power from these power plants to the consumer. This tangle of cables (okay, they're not really a tangle - they're far more organised and heavily engineered) form a nation's power grid.

An ideal power grid is a fully connected graph. That's why it's a grid - there's always a path from every single consumer to every single electricity producer in the system, so that if one power plant fails the consumer is always connected to all the other ones to be able to draw power from them.

However, with so many things connected to the power grid, things start getting complicated.

Let's begin with some high school physics. Joule's Law1 - the first one - says that the heat dissipated by a conductor is directly proportional to the square of the current that passes through it. That means that 1 ampere of current passing through a wire with 1 ohm of resistance will produce 1 joule of heat per second, but 2 amps of current passing through the same conductor will produce 4 joules of heat. A thousand amps of current will... produce enough heat to melt the wire and there will soon be no power grid.

The power grid has to carry tens to hundreds of gigawatts of power.

Notice that I said power, not current. An electrical appliance only cares about how much power it consumes. Power is the product of voltage and current, which means you can carry the same amount of power through a wire by using a low amount of current at an insanely high voltage. High voltages don't melt wires. Also, wires used in power grids have pretty low resistances - usually of the order of 10-10 ohms per meter, but that's still 0.001 Ohms for a 1000 km stretch of wire. If you do the math, a thousand amps of current will produce 10,000 joules of heat every second - or 10 kW of heat. That's a lot of wastage.

So electricity transmission happens at even lower amperages, and insanely high voltages. Common transmission lines operate at anywhere between 345 kilovolts to 750 kilovolts, but there are transmission systems that operate at 1000 kV. A full megavolt. At 1 MV, the current needed to transmit one megawatt of power is just one ampere.

Remember what I said about electrical appliances caring only about the power they consume? I lied... sort of. You can't just connect your television to a one megavolt power line. Potential differences (voltages) have real implications in the physical world - most importantly, if you bring a conductor at a +1 MV potential within a few metres of anything at ground potential (such as yourself), you'll get a brilliant flash of lightning and pretty soon that thing at ground potential will cease to exist. Air is a good insulator, but not enough to prevent an electrical arc between two objects at a million volts of difference.

So just before you deliver power to the consumers, you have to step down the voltage to something a little more sane. In Europe, India and most of the world that sane voltage is 230 volts. At that voltage, the amount of power that a common household consumes does not need a lot of amps to transmit. In the US that voltage is 110 volts, but the USA is a strange country so I will not attempt to explain this.

And here's where things start getting interesting. It turns out - due to something called inductive coupling2 - that you can pretty much convert between low voltage and high current to high voltage and low current, without (theoretically, anyway) any loss in power (i.e., the multiplication product of the voltage and current) by just wrapping the wires around a piece of metal in a specific way. The device used to do this is called a transformer, and transformers are an integral part of every power grid.

There's just one problem. Inductive coupling only works if the voltage in the conductor keeps changing all the time. And this is where alternating current (AC) comes in. With alternating current, the voltage constantly cycles from +230V to -230V, 50 times every second (in the EU, India and other not-strange countries). Okay, it cycles from +325V to -325V because 230V is the RMS voltage, not peak voltage, but that's just splitting hairs.

Remember these numbers. These are national standards. Every wall socket in an European country has to output 230V of AC electricity at a frequency of 50Hz. If it stops doing that, then Bad ThingsTM will happen.

Power Grids, Part 2

In part 1, we learnt that the power grid distributes power from power plants to homes and stuff. We also learnt that the power grid carries power at very high voltages and very low currents, and because it's so efficient to step down voltages at the consumer site using inductive coupling, the whole system uses alternating current.

In part 2, we learn that the power grid has one major drawback - it can only transmit power, not store it. So at any given point in time, all the power plants in the system together produce just as much power as all the consumers together need. No more, no less. All the power that is being produced has to be consumed.

So why can't we just produce more power than is required? Well, here's the deal. Most power generation in power plants is done using Synchronous Alternators. That's a fancy term for generators which generate alternating current at the exact same frequency that they're turning at. This means all the generators in power plants in Europe keep turning at 3000 RPM (50 rotations per second, for AC electricity at 50Hz).

Imagine you are driving your car on a level road, doing 50 KPH. Suddenly, you start going up an incline. Your speed starts dropping, because your wheels now start to turn more slowly. You need to press down harder on the accelerator to make your wheels go faster now, if you want to maintain that 50 KPH speed.

Synchronous Alternators work the same way. The more power you draw from them, the harder it gets to turn them. If whatever is driving that alternator - a diesel engine, a nuclear reactor, a gas turbine or something - does not step up its power output, the alternator will start turning more slowly, and the frequency of the power output will drop. Similarly, if you draw too little power, the driving engine will be turning the alternator with too much power, and it will turn faster than it needs to.

The load on the electrical grid changes every moment, because at any given moment someone is turning something off and someone else is turning something on. Power plants have to adjust their power output every milisecond. Unfortunately, a nuclear reactor, or a steam boiler, or a gas turbine is not like a car engine. You can't just press an accelerator pedal and make it instantly go vroom vroom. Power plants need a lot of time to react to load changes. Tens of seconds to full minutes, sometimes.

Frequency Containment Reserves

This is where the work that I do comes in.

Devices that hook up to the power grid tend to be pretty tolerant about voltage fluctuations, but not about frequency fluctuations. Indeed, some devices (including critical medical devices) rely on the power grid cycling exactly 50 times a second to count time. They measure one second by counting 50 cycles on their input current.

A 100 milihertz deviation of frqeuency is therefore considered a power grid emergency. This means (by EU standards) the power grid frequency can never drop below 49.9Hz and never go above 50.1Hz.

Frequency Containment is the process of controlling the frequency of the power grid. If we see that the frequency is too high, we create load to consume more power from the system and bring the frequency down. If we see that the frequency is too low, we deliver more power into the system (i.e., create a negative load) to bring the frequency of the grid up.

So how does FC become FCR? The R in FCR stands for Reserves. Batteries.

If you bring enough batteries together, you have the capacity to charge and discharge them really fast. Enough Lithium-Ion batteries in one place can be used to draw a massive amount of power from the grid in a very short amount of time. They can also inject a massive amount of power into the grid in just as short a period of time.

And so that's what FCR is. It's a giant uninterruptible power supply for a power grid. It draws or injects power from or into the power grid for the short spans of time that it takes for the power plants to react to changes in power demands and spin their generators faster or slower.

All national power grids have FCR units, typically operated by the power generation companies or the grid operators. In the continental European power grid, however, the FCR services market is open to all players, so there are private players with very innovative control technology competing with established publicly owned infrastructure service providers.

In fact, in the EU, even you as a private person can be an FCR provider. Do you have a giant battery (like a Tesla PowerWall) at home? Install some hardware that reacts to the grid frequency, hook it up to your power line with a grid-tie inverter, and tell your utility company that you'd like to provide local FCR services. TSOs (Transmission Service Operators, a fancy term for power grid operators) theoretically provide daily contracts to individuals who wish to provide FCR services with batteries in their homes. It's not really effective - one PowerWall can't really make much of a dent in the local grid, but in the current EU legal framework it's already possible to do it.

Best of all, as Europe switches to renewable energy, the FCR market is here to stay. Wind turbines and solar panels all generate fluctuating amounts of DC power depending on the sun and the wind, and need grid-tie inverters to convert that into AC power at grid voltages. Electronic inverters have their own set of problems that make maintaining a proper sinusoidal frequency even more difficult under constantly fluctuating loads, so FCR operators will need to provide more and more power balancing capacity.

I hope this was a good explanation of what FCR is. If you have questions or comments, please get in touch! Till next time, tschau!

KDevelop 5.2 released

A little more than half a year after the release of KDevelop 5.1, we are happy to announce the availability of KDevelop 5.2 today. Below is a summary of the significant changes -- you can find some additional information in the beta announcement.

We plan to do a 5.2.1 stabilization release soon, should any major issues show up.


With 5.1, KDevelop got a new menu entry Analyzer which features a set of actions to work with analyzer-like plugins. During the last 5.2 development phase, we merged more analyzer plugins into kdevelop.git which are now shipped to you out of the box:


Heaptrack is a heap memory profiler for C/C++ Linux applications.

heaptrack screenshotScreenshot of heaptrack run from the KDevelop plugin, visualizing memory usage of KDevelop.


cppcheck is a well-known static analyzer for C++, and can now also be run from within KDevelop by default, showing issues inline.

KDevelop with Cppcheck integration KDevelop with Cppcheck integration

Improved C++ support

A lot of work was done on stabilizing and improving our clang-based C++ language support. Notable fixes include:

  • Properly pass on some categories of compiler flags from the build system to the analyzer, fixing e. g. parse errors in some Qt header files which cannot be parsed if a certain compiler configuration is not respected
  • Improve performance of C++ code completion in some situations
  • Restore some completion features from 4.x, such as automatic insertion of semicolons in some cases

More improvements, such as better handling of template class member functions, are already being worked on and will be in one of the next versions of KDevelop.

Improved PHP language support

Thanks to Matthijs Tijink we've got many improvements for the PHP language support. The number of syntax warnings with modern PHP code should be greatly reduced, and the type inference is better. The improvements include added support for new language features, work on the type system, as well as bug fixes. Notable improvements include:

  • Add callable type to PHP. (commit. code review D7034)
  • Process member properties/calls for unsure types. (commit. code review D6923)
  • Fix uses of class in closure parameters and default values for functions. (commit. code review D6690)
  • Allow non-scalar constants. (commit. code review D6670)
  • Add spaceship and null coalesce operators. (commit. code review D6645)
  • Support more cases of function argument unpacking. (commit. code review D6271)
  • Support for variadic functions in documentation popup. (commit. code review D6256)
  • Implement syntax support for function argument unpacking. (commit. code review D5908)
  • Add support for variadic functions. (commit. code review D5703)
  • Support of Class::{expr}() syntax from Php 5.4. (commit. code review D4902)
  • Support for $this as an array when implementing ArrayAccess. (commit. code review D4776)
  • Php7 IIFE syntax parsing. (commit. fixes bug #370515. code review D4391)


PHP support in KDevelop 5.2

PHP support in KDevelop 5.2

Improved Python language support

Mostly thanks to Francis Herne, some cleanup has been done in the Python language plugin as well.

  • Fixed a false-positive warning when a name used in a closure was defined later in the file.
  • Fixed highlighting of local variables in comprehensions and of parameters in lambda definitions.
  • Infer the correct type when slicing a tuple with constant integers.
  • Infer the correct type from `and` or `or` expressions (Nicolás Alvarez).
  • Internal code cleanups.

Ongoing support for other platforms

We're continuously improving the Windows version of KDevelop. For the Windows version, we upgraded the Qt version to 5.9.1, the KF5 version to 5.37 and the LLVM/Clang version to 5.0.0. Also noteworthy, on Windows, we now also ship QtWebEngine instead of QtWebKit for the documentation browser.

Get it

Together with the source code, we again provide a prebuilt one-file-executable for 64-bit Linux, as well as binary installers for 32- and 64-bit Microsoft Windows. You can find them on our download page.

The 5.2.0 source code and signatures can be downloaded from here.

Should you find any issues in KDevelop 5.2, please let us know in the bug tracker.

sbrauch Tue, 2017/11/14 - 16:30


Sorry, I think You broke Qt Documentation because internal links don't work. Just try to open any page this documentation and clink on any link. You will go nowhere :(. Built documentation is no so much usable if I'm not able to navigate inside. Reported bug: 386929

Looking on changes in Cpp support, seems that KDevelop team focused here on improving python support. Skipping included addons like cppcheck and heaptrack the rest looks a bit poor :(.

Heaptrack looks absolutely fantastic, and is nicely integrated via the provided plugin - thanks a whole lot for this fantastic release once more, cementing my love for Kdevelop.

Keep it up folks!

This version is again better than the previous one. I finally got to make the click-on-file to output the right file instead of creating a new one when clicking on a file-line error/warning in the compilation output. The project from makes this work.
However, the code completion is very very slow and very very hungry. On a 16 cores CPU it still takes ages for a full indexing. And for simply updating little functions in a file, reindexing it can take up to one minute. Usual completion can work quite quickly or takes one minute to show up, or to show an irrelevant completion or even not show up.
But good work. I'm more and more please to use kedevelop which I use since before its 1.0 version :)

What about a section in which new features or bugfixes will be discussed for future versions. For example what a user should wait for 5.3?


In reply to by Petross404 (not verified)

It's quite difficult to do this. We don't exactly distribute developer resources among things some manager thinks are important, but rather there's a set of people who might or might not have time to work on what they might or might not find important. The general direction of the project is currently that we mostly aim to make the features we already have more stable, faster, and better.

thanks for such a great IDE! you mentioned full Support for CUDA in 5.2, but I couldn't find it in your release notes? is it rescheduled ?

Thanks a lot!

KTechLab, the IDE for microcontrollers and electronics, has reached a new milestone: its latest release, 0.40.0, does not depend on KDE3 and Qt3, but on KDE4 and Qt4. This means that KTechLab can be compiled and run on current operating systems.

Back from the OpenStack Summit in Sydney. It seems all my sessions were recorded this time. Here you can find the slides and videos:
  • Multicloud requirements and implementations: from users, developer, service providers (Panel Discussion) [video]
  • Email Storage with Ceph (Lightning Talk) [slides | video]
  • Vanilla vs OpenStack Distributions - Update on Distinctions, Status, and Statistics (Talk) [slides | video]

Hi there,

It's been a while since my last post over here. After being drained with a lot of work on the very first edition of QtCon Brasil, we all had to take some rest to recharge our batteries and get ready for some new crazinesses.

This post is a short summary of the talk I presented at Akademy 2017, in the quite sunny Almería in Spain. Akademy is always a fascinating experience and it's actually like being at home, meeting old friends and getting recurrently astonished by all awesomeness coming out of KDE community :).

My talk was about architecting Qt mobile applications (slides here | video here). The talk started with a brief report on our Qt mobile development experiences at IFBa in the last two years and then I explained how we've been using lean QML-based architectures and code generators to leverage the productivity and provide flexible and reusable solutions for Qt mobile applications.

Our approach ‒ named Meg ‒ is defined by two major components: a lean dynamic QML-based architecture for Qt mobile applications and a code generator for enabling the creation of modular RESTful servers and Qt mobile applications. Meg provide a Ruby-based CLI, built on top of Thor CLI framework, with templates specified in ERB (Embedded RuBy). We also designed a nice architecture for the generator itself, so that new templates can be defined as new Thor modules. The framework that implements the lean architecture we designed for Qt mobile applications already provides a JSONListModel QML object, making it easier to implement RESTful Qt clients.

The following templates are currently available:

  • Sinatra RESTful server with modular architecture (sinatra-server)
  • Ruby Sinatra RESTful service plug-in (sinatra-service-plugin)
  • Simple Qt mobile app with plugin-based architecture (simple-app)
  • Qt mobile RESTful app with plugin-based architecture (restful-app)
  • Qt mobile RESTful client plug-in (restful-client-plugin)

You're welcome to try it :) Here is what you need to do:

* git clone
* install ruby
* run ‘gem install bundler’
* Run ‘bundle install’
* Meg CLI is available in ‘./bin/meg’

Creating a simple plugin-based QML application

So, these are the steps to create a simple plugin-based QML application using Meg:

1. Create a new project using simple-app as project type (template):
./bin/meg new SimpleApp -t simple-app
2. Create a new plugin, for example, to display students information:
./bin/meg generate plugin students -t basic-plugin -a simpleapp/
3. Create another plugin, for example, to display teachers information:
./bin/meg generate plugin teachers -t basic-plugin -a simpleapp/

In step 1, we create a new project in the simpleapp directory, using the basic-plugin template (-t option). In steps 2 and 3, we create two plugins (students and teachers), using the basic-plugin template and install them at simpleapp directory. After that, your application is available at simpleapp directory and can be built by a normal qmake/make run.

Here is what you get out of those steps:

Creating a Sinatra-based RESTful server

Besides automating the creation of Qt-based mobile clients, Meg also provides some templates for generating RESTful servers based on Sinatra Ruby microframework. As in the client-side, we also designed a plugin-based architecture for the RESTful server, where new services are provided by separate modules. Here are the steps to create a new RESTful server:

1. Create the server project:
./bin/meg new myserver -t sinatra-server
2. Create a plugin for handling CRUD operations for an application for visualizing a conference program:
./bin/meg generate plugin Conference -t sinatra-service-plugin -a myserver/ acronym:string name:string city:string country:string venue:string start_date:datetime end_date:datetime
3. Create a similar plugin for handling CRUD operations for handling speakers:
./bin/meg generate plugin Speaker -t sinatra-service-plugin -a myserver/ name:string affiliation:string shortbio:string

To run the server you first need to setup the database:

$ cd myserver
$ rake db:migrate

And populate some data:

$ sqlite3 db/development.sqlite3
insert into conferences values (1, 'QtCon-BR', 'QtCon Brasil', 'São Paulo', 'Brasil', 'Espaco Fit', '2017-08-18 09:00:00', '2017-08-20 18:00:00');
insert into conferences values (2, 'Akademy', 'Akademy', 'Berlin', 'Germany', 'BCC', '2017-03-01 09:00:00', '2017-03-03 18:00:00');
insert into conferences values (3, '', '', 'Guwahati', 'India', 'IIT', '2017-03-10 09:00:00', '2017-03-12 18:00:00');
insert into speakers values (1, 'Our beloved Konqi', 'KDE', 'Konqi is awesome');
insert into speakers values (2, 'Dirk Gently', 'Adams', 'He is a holistic detective');

Now, you can start the server:

$ ruby myserver.rb

Creating a Qt-based RESTful client

Creating a Qt-based RESTful client for our server is also quite simple:

$ ./bin/meg new MyApp -t restful-app
$ ./bin/meg generate plugin conferences -t restful-client-plugin -a myapp -i name -c university acronym:string name:string city:string venue:string start_date:datetime end_date:datetime
$ ./bin/meg generate plugin speakers -t restful-client-plugin -a myapp -i name -c microphone name:string affiliation:string shortbio:string

Such commands create a new Qt mobile project, using the restul-app template. Then, two RESTful client plugins for the aforementioned services are created and installed in the project directory. You can now build your Qt mobile client and, once started the server, this is what you get out from it:


So, that's all folks! We hope this can improve somehow the development workflow and of RESTful-based Qt mobile applications. This is a one-year project being carried out at IFBa by myself and Eliakin Costa. Hopefully, we'll get back with some news soon.

See you!

November 13, 2017

Latte Dock, the very popular doc/panel app for Plasma Desktop, has released its new bugfix version 0.7.2. This is also the first stable release since Latte Dock became an official KDE project at the end of August.



Version 0.7.1 was added to our backports PPA in a previous round of backports for Kubuntu 17.10 Artful Aardvark.

Today that has been updated to 0.7.2, and a build added for Kubuntu 17.04 Zesty Zapus users.

The PPA can be enabled by adding the following repository to your software sources list:


or if it is already added, the updates should become available via your preferred update method.

The PPA can be added manually in the Konsole terminal with the command:

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

and packages then updated with

sudo apt update
sudo apt full-upgrade

Upgrade notes:

~ The Kubuntu backports PPA includes various other backported applications and Plasma releases, so please be aware that enabling the backports PPA for the first time and doing a full upgrade would result in a substantial amount of upgraded packages in addition to Latte Dock.

~ The PPA will also continue to receive further bugfix updates when they become available, and further updated releases of Plasma and applications where practical.

~ While we believe that these packages represent a beneficial and stable update, please bear in mind that they have not been tested as comprehensively as those in the main Ubuntu archive, and are supported only on a limited and informal basis. Should any issues occur, please provide feedback on our mailing list [1], IRC [2], and/or file a bug against our PPA packages [3].

1. Kubuntu-devel mailing list:
2. Kubuntu IRC channels: #kubuntu & #kubuntu-devel on
3. Kubuntu PPA bugs:

Latte Dock v0.7.2   has been released containing many important fixes and improvements!

KDE Project

Latte managed to pass the kde review process and become an official kde project! It can be found in extragears (this is where projects with independent release schedule are landed). By becoming a kde project Latte has already benefited in many areas, many more translations through kde localization teams, plasma devs sharing their knowledge in qt, qml etc. etc.

Please everyone using 0.7.1 update to 0.7.2 as this should fix any crashes relevant to qt>=5.9.2 and at the same time it should provide you with a more concrete exprerience.

Go get   0.7.2  from,*


  • fix crashes introduced with qt 5.9.2 when the user hovers the dock, after deleting some applets etc.
  • highly improve the attention bouncing animation
  • fix coloring for shortcut badges
  • various fixes for animations and glitches
  • hide internal tasks separator at the edges
  • improvements for window manager disabled compositing window state
  • fix small issues with title tooltips
  • pass kde review process
  • move source to kde infrastructure
  • more translations from kde localization teams

* archive has been signed with gpg key: 325E 97C3 2E60 1F5D 4EAD CF3A 5599 9050 A2D9 110E

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.