24 Nov 2017

feedPlanet KDE

Mini Bug Squashing Day

In preparation for the 17.12 release we will be holding a mini bug squashing day on the 1st of December, between 10:00 and 15:30 (CET time). Community members are invited to submit their bug suggestions. For developers interested in contributing to the project we have a set up a list of low hanging bugs for them to cherry pick and get acquainted with the code base. Note that this is a great opportunity for prospective participants in the Season of KDE.

During that day, we will be available on IRC in the #kdenlive channel. For those who didn't follow the recent cafés, Kdenlive's big refactoring release has been postponed to 18.04, because we haven't yet reached the required stability to satisfy our growing userbase. This means that Kdenlive 17.12 will be the last release for the old codebase. This bug squash event is an occasion to fix some small issues and improve Kdenlive's experience for the next 4 months.

Feel free to join us in that effort!

24 Nov 2017 10:48am GMT

KDevelop 5.2.1 released

KDevelop 5.2.1 released

Just a few days after the release of KDevelop 5.2.0, we today provide a stabilization and bugfix release with version 5.2.1. This is a bugfix-only release, which introduces no new features and as such is a safe and recommended update for everyone currently using KDevelop 5.2.0.

You can find the updated Windows 32- and 64 bit installers, the Linux AppImage, as well as the source code archives on our download page.

Issues fixed:

  • Fix a crash which often happened when switching git branches in the background in C++ projects. This temporarily disables documentation warnings, as well as parsed documentation display in the tooltips, until the underlying issue is fixed upstream. (bug, upstream bug)
  • Fix no compiler being set by default on Windows, causing KDevelop to fail finding the C++ standard library. (bug)
  • Fix standard library paths not being passed as include paths when using clang as compiler on windows. (review)
  • Fix a crash happening on some systems when opening a session. (bug)
  • Fix include path completion not showing project-defined system includes (i.e. includes added as system includes but by your project). (bug)
  • Fix crash when batch-editing defines in the define editor. (bug)
  • Fix an assert (only happened in debug mode) and potential crash when showing problem tooltip. (bug)
  • Fix links in documentation browser not working in the AppImage. (bug)
  • Fix build failure when building in-source when translations are present. (bug)
  • Fix a crash when showing navigation tooltip in PHP projects in some situations. (bug)
  • Fix targets being duplicated when using CMake subprojects. (bug)
  • Fix console toolview asking to delete a temporary file interactively. (bug)
  • Fix a lot of AUTOMOC warnings while compiling with CMake 3.10
  • Fix some tool view context menus having empty entries. (bug)
  • Fix the progress widget in the statusbar not showing in some sessions. (review)
  • Adapt cache clear logic to ensure that the code model cache (~/.cache/kdevduchain) is always cleared when changing to a different KDevelop version (including patch versions). Unsuitable data in the cache has caused a range of issues in the past, including crashes. If you really need to keep the cache, you can create an (empty) file with the version suffix of the target version in the cache folder.
  • Fix KDevelop not starting up with the welcome page enabled (which it is by default) on systems without OpenGL support. (bug)
  • Fix build with Qt version 5.5.
  • Fix file templates not working on Windows (this fix should be in the Windows 5.2.0 installers already, but was not in the source tarballs).

Please let us know of any issues you encounter when using KDevelop on the bug tracker, in the mailing lists for development or users (kdevelop@kde.org, kdevelop-devel@kde.org), or in the comment section of this release announcement.

We think KDevelop 5.2.1 should work quite well now, but if more issues show up, we will provide another bugfix release shortly.

sbrauch Fri, 2017/11/24 - 11:00


24 Nov 2017 10:00am GMT

23 Nov 2017

feedPlanet KDE

GHCI 2017 : Big thanks to KDE!

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!

23 Nov 2017 6:07pm GMT

Say hello to Qt Quick Pointer Handlers

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.

23 Nov 2017 4:33pm GMT

Are you ready for Qt Quick Controls 2.3?

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.

23 Nov 2017 2:36pm GMT

IKEA Trådfri first impressions

Warm white lightsWarm white lightsSince 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

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.

23 Nov 2017 2:28pm GMT

How to emulate Plasma Mobile on your machine with qemu

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.

qemu-img create -f raw neon-unstable.img 10G

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

KDE Neon Installation

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

curl http://neon.plasma-mobile.org:8080/Pangea%20CI.gpg.key | sudo apt-key add -
sudo add-apt-repository http://neon.plasma-mobile.org:8080

sudo apt update && sudo apt upgrade

KDE Neon install updates

apt install plasma-phone-components plasma-phone-settings

SDDM Plasma Mobile

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.

23 Nov 2017 1:40pm GMT

Qt Quick Controls 2: Imagine Style

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.

23 Nov 2017 9:14am GMT

22 Nov 2017

feedPlanet KDE

Qt Creator 4.5 RC released

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 chat.freenode.net). 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 chat.freenode.net, and on the Qt Creator mailing list.

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

22 Nov 2017 12:20pm GMT

Qt 5.9.3 Released

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 qt.io Download page for open-source users.

The post Qt 5.9.3 Released appeared first on Qt Blog.

22 Nov 2017 11:54am GMT

Security advisory about Qt for Android

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.

22 Nov 2017 11:54am GMT

21 Nov 2017

feedPlanet KDE

Akademy 2017 talk

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.

21 Nov 2017 3:51am GMT

20 Nov 2017

feedPlanet KDE

Writing a Custom Qt 3D Aspect – part 1


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

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.

20 Nov 2017 2:31pm GMT

19 Nov 2017

feedPlanet KDE

Improved data fitting in 2.5

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.

19 Nov 2017 8:05pm GMT

Atelier and the social networks

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

19 Nov 2017 2:01pm GMT

18 Nov 2017

feedPlanet KDE

Monitoring 3DPrinters with Atelier

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

18 Nov 2017 2:15pm GMT