Smooth animations using the QtQuick Canvas

Google's Material Design showcases a few nicely detailed animations that add life to the user interface. QML makes it straightforward to create the traditional moving, scaling and opacity change animations while taking advantage of the GPU, but how can we create an animation changing the shape of an element and not merely transforming it?

Today we'll see how we can use the QML Canvas item to create an animated simplified version of the Android's drawer and back arrow button.

We'll make sure that we use the GPU to accelerate the rendering and use standard QtQuick animations to control the drawing evolution, as conveniently as with traditional transform animations.

Since you can animate any property in QML, not only the built-in ones, you can define the animation parameters declaratively as properties and then use those as input for your JavaScript Canvas drawing code, requesting a repaint each time an input changes.

Drawing the base

Let's start with a static rendering of our drawer icon, drawing three horizontal bars:

import QtQuick 2.0
Canvas {
    id: canvas
    width: 256
    height: 256

    onPaint: {
        var ctx = getContext('2d')
        ctx.fillStyle = 'white'
        ctx.fillRect(0, 0, width, height)

        var left = width * 0.25
        var right = width * 0.75
        var vCenter = height * 0.5
        var vDelta = height / 6

        ctx.lineCap = "square"
        ctx.lineWidth = vDelta * 0.4
        ctx.strokeStyle = 'black'

        ctx.beginPath()
        ctx.moveTo(left, vCenter - vDelta)
        ctx.lineTo(right, vCenter - vDelta)
        ctx.moveTo(left, vCenter)
        ctx.lineTo(right, vCenter)
        ctx.moveTo(left, vCenter + vDelta)
        ctx.lineTo(right, vCenter + vDelta)
        ctx.stroke()
    }
}

Which gives us:

Using QML properties to drive the animation

Then let's add the animation logic for the rotation. Use a State, triggered when the arrowFormState boolean property is true, make our whole drawing rotate by 180 degrees in that state and specify how we want it to be animated:

    property bool arrowFormState: false
    function toggle() { arrowFormState = !arrowFormState }

    property real angle: 0
    states: State {
        when: arrowFormState
        PropertyChanges { angle: Math.PI; target: canvas }
    }
    transitions: Transition {
        NumberAnimation {
            property: "angle"
            easing.type: Easing.InOutCubic
            duration: 500
        }
    }

Each time one of our animated values change, tell the canvas to paint itself:

    onAngleChanged: requestPaint()

The Canvas is using the software rasterizer by default, this permits using functions like getImageData() without problems (which is slow if the pixels are lying in graphics memory). In our case however, we prefer having our drawing rendered as fast as possible to allow a smooth animation. Use the FramebufferObject renderTarget to use the OpenGL paint engine and the Cooperative renderStrategy to make sure that OpenGL calls are made in the QtQuick render thread:

    renderTarget: Canvas.FramebufferObject
    renderStrategy: Canvas.Cooperative

Finally simply use the animated value of our Canvas' angle QML property in our JavaScript drawing code:

    onPaint: {
        var ctx = getContext('2d')
        // The context keeps its state between paint calls, reset the transform
        ctx.resetTransform()

        // ...

        // Rotate from the center
        ctx.translate(width / 2, height / 2)
        ctx.rotate(angle)
        ctx.translate(-width / 2, -height / 2)

        // ...
    }

In practice we'll react to input events from a MouseArea, but for the sake of keeping the code simple in this demo we use a Timer to trigger a state change:

    Timer { repeat: true; running: true; onTriggered: toggle() }

And this is what we get:

Taking advantage of existing animations

Pretty, although it would be nicer if the rotation would always be clockwise. This is possible to do with a NumberAnimation, but QtQuick already provides this functionality in RotationAnimation, we can just tell it to update our custom angle property instead. Since QtQuick uses degrees, except for the Canvas API which requires radians, we'll convert to radians in our paint code:

    states: State {
        when: arrowFormState
        PropertyChanges { angle: 180; target: root }
    }
    transitions: Transition {
        RotationAnimation {
            property: "angle"
            direction: RotationAnimation.Clockwise
            easing.type: Easing.InOutCubic
            duration: 500
        }
    }
    onPaint: {
        // ...
        ctx.rotate(angle * Math.PI / 180)
        // ...
    }

This time it rotates clockwise for both transitions:

Change the shape based on animation parameters

Lastly we'll add the morphing logic. Create a new morphProgress property that we'll animate from 0.0 to 1.0 between the states, derive intermediate drawing local variables from that value and finally use them to animate the position of the line extremities between state changes. We could use a separate property for each animated parameter and let Qt animations do the interpolation, but this would spread the drawing logic around a bit more:

    property real morphProgress: 0
    states: State {
        // ...
        PropertyChanges { morphProgress: 1; target: canvas }
    }
    transitions: Transition {
        // ...
        NumberAnimation {
            property: "morphProgress"
            easing.type: Easing.InOutCubic
            duration: 500
        }
    }

    onMorphProgressChanged: requestPaint()

    onPaint: {
        // ...
        // Use our cubic-interpolated morphProgress to extract
        // other animation parameter values
        function interpolate(first, second, ratio) {
            return first + (second - first) * ratio;
        };
        var vArrowEndDelta = interpolate(vDelta, vDelta * 1.25, morphProgress)
        var vArrowTipDelta = interpolate(vDelta, 0, morphProgress)
        var arrowEndX = interpolate(left, right - vArrowEndDelta, morphProgress)

        ctx.lineCap = "square"
        ctx.lineWidth = vDelta * 0.4
        ctx.strokeStyle = 'black'
        var lineCapAdjustment = interpolate(0, ctx.lineWidth / 2, morphProgress)

        ctx.beginPath()
        ctx.moveTo(arrowEndX, vCenter - vArrowEndDelta)
        ctx.lineTo(right, vCenter - vArrowTipDelta)
        ctx.moveTo(left + lineCapAdjustment, vCenter)
        ctx.lineTo(right - lineCapAdjustment, vCenter)
        ctx.moveTo(arrowEndX, vCenter + vArrowEndDelta)
        ctx.lineTo(right, vCenter + vArrowTipDelta)
        ctx.stroke()
        // ...
    }

Which gives us our final result:

Wrapping it up

This is a simple example, but a more complex drawing will both be more difficult to maintain and risk hitting performance bottlenecks, which would defeat the purpose of the approach. For that reason it's important consider the limits of the technology while designing the UI.

Even though not as smooth or responsive, an AnimatedImage will sometimes be a more cost effective approach and require less coordination between the designer and the developer.

Performance and resources

Yes we're using the GPU, but the Canvas also has costs to consider:

  • Every Canvas item will allocate a QOpenGLFramebufferObject and hold a piece of graphics memory.
  • Each pixel will need to be rendered twice for each frame, once onto the framebuffer object and then from the FBO to the window. This can be an issue if many Canvas items are animating at the same time of if the Canvas is taking a large portion of the screen on lower-end hardware.
  • The OpenGL paint engine isn't a silver bullet and state changes on the Canvas' context should be avoided when not necessary. Since draw calls aren't batched together, issuing a high number of drawing commands can also add overhead and reduce OpenGL's ability of parallelizing the rendering.
  • Declarative animations are great, but since we are writing our rendering code in JavaScript we are losing a part of their advantage and must accept a small overhead caused by our imperative painting code.

This leads us to our next blog post, next week we'll see how we can reduce the overhead to almost nothing by using a much more resource effective QML item: the ShaderEffect. You can subscribe via RSS or e-mail to be notified.

Complete code

import QtQuick 2.0
Canvas {
    id: canvas
    width: 256
    height: 256

    property bool arrowFormState: false
    function toggle() { arrowFormState = !arrowFormState }

    property real angle: 0
    property real morphProgress: 0
    states: State {
        when: arrowFormState
        PropertyChanges { angle: 180; target: canvas }
        PropertyChanges { morphProgress: 1; target: canvas }
    }
    transitions: Transition {
        RotationAnimation {
            property: "angle"
            direction: RotationAnimation.Clockwise
            easing.type: Easing.InOutCubic
            duration: 500
        }
        NumberAnimation {
            property: "morphProgress"
            easing.type: Easing.InOutCubic
            duration: 500
        }
    }

    onAngleChanged: requestPaint()
    onMorphProgressChanged: requestPaint()

    renderTarget: Canvas.FramebufferObject
    renderStrategy: Canvas.Cooperative

    onPaint: {
        var ctx = getContext('2d')
        // The context keeps its state between paint calls, reset the transform
        ctx.resetTransform()

        ctx.fillStyle = 'white'
        ctx.fillRect(0, 0, width, height)

        // Rotate from the center
        ctx.translate(width / 2, height / 2)
        ctx.rotate(angle * Math.PI / 180)
        ctx.translate(-width / 2, -height / 2)

        var left = width * 0.25
        var right = width * 0.75
        var vCenter = height * 0.5
        var vDelta = height / 6

        // Use our cubic-interpolated morphProgress to extract
        // other animation parameter values
        function interpolate(first, second, ratio) {
            return first + (second - first) * ratio;
        };
        var vArrowEndDelta = interpolate(vDelta, vDelta * 1.25, morphProgress)
        var vArrowTipDelta = interpolate(vDelta, 0, morphProgress)
        var arrowEndX = interpolate(left, right - vArrowEndDelta, morphProgress)

        ctx.lineCap = "square"
        ctx.lineWidth = vDelta * 0.4
        ctx.strokeStyle = 'black'
        var lineCapAdjustment = interpolate(0, ctx.lineWidth / 2, morphProgress)

        ctx.beginPath()
        ctx.moveTo(arrowEndX, vCenter - vArrowEndDelta)
        ctx.lineTo(right, vCenter - vArrowTipDelta)
        ctx.moveTo(left + lineCapAdjustment, vCenter)
        ctx.lineTo(right - lineCapAdjustment, vCenter)
        ctx.moveTo(arrowEndX, vCenter + vArrowEndDelta)
        ctx.lineTo(right, vCenter + vArrowTipDelta)
        ctx.stroke()
    }
    Timer { repeat: true; running: true; onTriggered: toggle() }
}

New Unified Qt Online Installer Available

Today we released a new unified online installer for commercial and open-source versions. Previously, we have had  separate installers for each version. Now Qt Account is used for validating the Qt license and determining if a commercial  or open-source version should be installed.

Unification of Qt systems has been ongoing for a while and we have now reached a major milestone with the unified online installer. We no longer have two separate online installers to create, test and release. Also, it is now easier to migrate from open-source to commercial license of Qt.

The Qt repositories and delivery networks for commercial and open-source content are still separate, so that users with a commercial license of Qt will have access to their commercial delivery system and the additional content their license grants them access to. Users without a commercial license will be able to install the open-source version of Qt from the open-source delivery system.

If you already have a Qt Account, enter your credentials when asked:

unified_installer_1

If you do not yet have a Qt Account, you can create it conveniently from the online installer:

unified_installer_2

When you enter your Qt Account credentials, the installer will check if there is a valid commercial license associated with your Qt Account, and you will be taken through to commercial installation. If there is no commercial license associated with your Qt Account, installation will provide the open-source version of Qt. If you do not have a Qt Account yet, you can simply create one directly via the installer. Just enter your email (this is address to which your account activation email will be immediately sent upon account creation) and the password you wish to use for Qt Account access and proceed to install. Be sure to activate your Qt Account as instructed in the email. You may also create a new Qt Account at qt.io, if you prefer.

In addition to being the place to manage support tickets and downloads for commercial license holders of Qt, Qt Account credentials are used for signing in to the Qt Wiki and Forum. We are also working hard to extend the use of Qt Account for sign in to other systems, such as bugreports.qt.io. To see a list of benefits of the Qt Account, please visit our Qt Account Benefits page.

The unified online installer is built with the brand new 2.0 version of the installer framework. We have worked hard to iron out all possible glitches of the installer, but in case you have problems with it, please file a bug to bugreports.qt.io. Offline installers are unchanged and still use the older version of installer framework.

If you are already using a Qt online installer, you will be provided the new unified installer when using the maintenance tool. You will need to update the installer (maintenance tool), before you download other items. If you do not yet have an online installer for Qt, you can get it from the qt.io Download page or from the Qt Account portal.

The post New Unified Qt Online Installer Available appeared first on Qt Blog.

Experts Wanted: Call for Papers | Qt World Summit 2015

by Nils Christian Roscher-Nielsen (Qt Blog)

We have now officially opened the Call for Papers for Qt World Summit. The Qt World Summit is the global event for all things Qt. Here, whether you are a tech strategist or a developer (even both for that matter), you can meet like-minded peers for networking and discussions, as well as learning about creating exceptional applications and devices that your users love. We plan to build the summit around these big themes:

  • Internet of Things systems and creating connected devices
  • Qt as the software solution for multi-platform development – desktop, mobile and embedded
  • The modern C++ standards and benefits
  • Automotive and industrial HMI trends
  • Creation of modern desktop user interfaces
  • Enterprise multi-screen development strategies
  • High-end UX on low-power embedded devices

The Qt World Summit will consist of two inspiring and educational days starting with keynotes from the creators of Qt and top industry leaders who will share their experiences with Qt. After being updated on the Qt roadmap, we will offer you a variety of sessions covering everything from technology strategy and product lifecycle management to in-depth technical talks on new APIs, best practices and live coding sessions all presented by Qt contributors and industry experts from around the world.

In the call for papers you will find three main talk categories: Qt Technology Strategy, Qt Application Development and Device Creation, and Seeking Innovation. More details to be found here. We invite all of you, from within the Qt community and the related industries, to submit your suggestions and abstracts. We are looking forward to your contribution and together make the best Qt event to date. Download the guidelines.

The conference also wouldn’t be nearly as amazing without our sponsors. We are very happy to have KDAB as our Diamond sponsor, showing their strong and continued commitment to the Qt ecosystem especially after their great effort of organizing the previous Qt Developer Days. A huge thanks also to e-GITS and Froglogic as Gold sponsors, and basysKom as Silver sponsor.

qtws15-sponsors-2015.04.30

We also welcome more support so if you are considering sponsoring to get your message out to an amazing audience, please review the Sponsor Prospectus.

The post Experts Wanted: Call for Papers | Qt World Summit 2015 appeared first on Qt Blog.

Windows 10 Support in Qt

Exciting times are ahead for the Microsoft Windows platform, so we want provide you with an update on our plans. Windows 10 is approaching and there is a large amount of improvements coming with Qt 5.5, making the WinRT / Windows Store Applications support better. With this improvements, we would also like to announce that starting with Qt 5.5 we will offer the Qt port of WinRT/Windows Store Applications under the LGPLv3/GPLv2+/Commercial licenses.

Windows 10 Provides Compatibility with Existing Qt Applications

Microsoft has indicated that they are planning to release Windows 10 this summer, so many Qt users have been curious about the support level we are aiming to provide with Qt 5.5 and subsequent releases.

The good news is that all Qt applications created with earlier Windows versions will run on Windows 10 without any limitation. That includes classic desktop (Win32) applications as well as Windows Store Applications (WinRT). One thing to mention is that on Windows 10 also the Windows Store Applications will be windowed and not only in full-screen anymore. This is supported already if you have an application in the Windows Store and Qt 5.5 will provide further improvements to smoothen glitches on resizing.

Qt Offers Portability from Win32 to WinRT

The new API for Windows Store Applications (WinRT) is very different from the Win32 API used by the classic Windows applications. Therefore, a developer who has created a native Windows application needs to in essence re-create the application to use the new API for Windows Store Applications. Fortunately, the situation is much better with Qt-based Windows applications.

For any application which uses just the functionality provided by Qt, the only required step is to recompile your Qt for Windows application with WinRT port of Qt to make it a Qt for Windows Store Application. If your application uses native Win32, some further work is needed, but the Qt parts are really easy. Unfortunately, the automatic styling functionality is not available for the WinRT port of Qt, so although both widgets and Qt Quick work well, the application does not automatically get the platform style.

Improvements to the Qt for WinRT (Windows Store Applications)

Microsoft’s new API for Windows Store Applications is available in PCs, tablets, phones, and later on, also on embedded devices. A great value is that the same application can run across a wide variety of devices, and all the different kinds of devices can access the common store for applications. Qt applications have been available for earlier versions of both Windows Phone and WinRT for a while now, and we can leverage the same baseline for Qt 5.5 and Windows 10 support.

For Qt 5.5 we have put a lot of effort into further stabilizing and improving the quality of our existing Qt for WinRT port, which supports all variances of Windows Store Apps (desktop and phone). We have been going through the feedback from previous releases and addressed all the most requested items. Qt 5.5 greatly improves, for example, Multimedia support and Visual Studio integration/deployment.

Support for Visual Studio 2015

So far Qt for WinRT applications have been built with Visual Studio 2013, which continues to work with Windows 10. There is also a new compiler coming later this year in Visual Studio 2015, which is a major update on the development environment. Visual Studio 2015 Community Technology Preview (CTP) has been out for a while, so we have been doing some research on how Qt behaves against that and some commits are already in the 5.5 branch, while others are still a work-in-progress. Visual Studio 2015 is still under heavy development, so there are currently some workarounds needed to build Qt with it. After the final version is out, we intend to provide support for it in a Qt 5.5.x patch-level release, including pre-built binaries.

Furthermore, the first preview of the Windows 10 SDK has been released, which is valid for Windows Store Apps, including Windows 10 Mobile. We are able to compile Qt against that SDK as well, with a couple of changes required. Similarly as for Visual Studio 2015, we are planning to fully support Windows 10 SDK, after it is officially released.

Use of LGPLv3/GPLv2+/Commercial License

With Qt 5.5 we are changing the license of the Qt for WinRT port to be LGPLv3 / GPLv2+ / commercial license. We believe that LGPLv3 is a better and clearer license than the older LGPLv2.1, so we want to use it for WinRT / Windows Store Applications in Windows 10 (as well as Windows 8.1 and Windows Phone 8.1). The open-source licenses LGPLv3 and GPLv2+, as well as the commercial licenses of Qt, are compatible with Microsoft’s terms and conditions for the Windows Store.

To learn more why we want to use LGPLv3 in Qt and what it means, please check the blog post about introducing LGPLv3 license option and qt.io licensing pages.

Full Support for Windows 10 Coming with Qt 5.5.x

As Qt 5.5.0 is scheduled to be released before Windows 10, we aim to provide full support for Windows 10 with a Qt 5.5.x patch release after Windows 10 is available. Our intention is to provide initial support for Windows 10 already with the Qt 5.5.0 release, so that users can try out Qt on Windows 10 preview versions. As also the Qt applications created with earlier Windows versions will run nicely in Windows 10, we see that things are in good shape for the upcoming major new Windows release.

The post Windows 10 Support in Qt appeared first on Qt Blog.

qbs 1.4.0 released

We are happy to announce the release of qbs 1.4.0 today.

What’s new?

In addition to lots of bugfixes and smaller improvements, this release also brings a number of new features:

  • With the new builtByDefault property, it is now possible to specify that a product should not be built unless that is explicitly requested. One useful application of this feature is the new item AutotestRunner, which provides functionality similar to “make check”.
  • Files are now by default installed as part of the build process, in order to allow products that work on the contents of the installation directory (see the item below).
  • There is now an archiver module, which we use to implement the InstallPackage item.
  • We have added experimental Android support, for projects with or without native code. Note that there is no special support for Qt yet, and Qt Creator integration is also missing.

Try it!

Source packages and a binary package for windows can be downloaded here.

Other relevant links

Wiki: http://qt.io/wiki/qbs
Documentation: http://qt.io/doc/qbs/index.html
Bug tracker: https://bugreports.qt.io/browse/QBS
Mailing list: http://lists.qt-project.org/mailman/listinfo/qbs

The post qbs 1.4.0 released appeared first on Qt Blog.

Qt Japan Summit 2015

We are happy to announce Qt Japan Summit in Akihabara on Tuesday, May 26 this year. Join us!

Tokyo, Japan: May 26

Last year’s Qt Developer Day Tokyo was a successful event with 300+ attendees joining a full day of technical tracks focused on embedded, desktop, mobile and multi-screen development. With a clear growing interest in Qt, we will return this year to keep the Qt momentum going in Japan and interact with businesses, Qt lovers, supporters and new Qt users.

Japan has been a friend of Qt and champion for the past several years where leading companies in automotive, consumer electronics, robotics & automation have standardized on Qt. We continue to find a bustle of energy from the local community and are grateful for the support. We are excited to position Qt Japan Summit as a part of the Qt World Summit happening later this year where our aim is to continue supporting the Qt Japan ecosystem.

The agenda & registration for the Qt Japan Summit is already available, and we recommend that you stay tuned to our channels including Qt.io/qtjapansummit and the twitter hashtag #QtJS.

japansummit-nsl-apr15

The post Qt Japan Summit 2015 appeared first on Qt Blog.

Qt Creator 3.4.0 released

We are happy to announce the release of Qt Creator 3.4.0 today. I’m highlighting some of the many new features below. Please take a look at our change log for a more complete list of features and fixes.

The C++ support in Qt Creator now has a new refactoring action that moves all function definitions out of a class declaration. We also added auto-completion for signals and slots in Qt 5 style connects. Just type the “&” and let auto-completion figure out the type of the object. Also new is a locator filter, All Included C/C++ Files, which finds all files that are used in your project by including them, even if they are not explicitly mentioned in your project. The filter is part of the default that is used when you just type in the Locator input field, and shares the shortcut string with Files in Any Project.

For users of the Professional or Enterprise edition we added experimental integration for Qt Test based auto tests and Qt Quick tests. It adds another navigation pane Tests, which lists the tests defined in your project, provides ways to run individual or sets of tests, and nicely shows test results in a new Test Results output pane. To try it, open Help > About Plugins (Qt Creator > About Plugins, on OS X), turn on Utilities > AutoTest, and restart Qt Creator. We also moved the Clang static analyzer integration out of experimental state. If you have at least Clang 3.6 installed, it now also supports using it with MSVC and MinGW. We also added suppression of individual diagnostics for a file, and a new page in Projects mode for managing these.

Other new features include

  • Changing the environment for running external tools
  • Searching through QML Profiler event notes
  • Using 64bit Android tool chains
  • Using generic projects for bare metal development
  • Highlighting of parenthesis in generic highlighters

See the change log for more.

You find the opensource version on the Qt download page, and Enterprise packages on the Qt Account Portal. Please post issues in our bug tracker. You also can find us on IRC on #qt-creator on irc.freenode.net, and on the Qt Creator mailing list.

The post Qt Creator 3.4.0 released appeared first on Qt Blog.

Qt Contributors’ Summit is coming closer

Hello!

This is a friendly reminder that the Qt Contributors’ Summit is coming soon. June is only a month and a half away and Spring is well on it’s way in Oslo.

We will be gathering in Oslo, starting with an unofficial pre-event on the 5th June and the Summit on the weekend of 6th – 7th. If you are coming, please register by the end of this month with the registration form.

For those of you not familiar with the Qt Contributors’ Summit, it is a two day event for people contributing to the Qt project in some way. We gather to discuss the current state and future of the project. Everyone who shares our passion for Qt is welcome.

The wiki pages for the event are now online too. For those of you coming, the Program page is especially important, as the event format is an unconference. This means that the attendees can, and should, reserve slots for discussions and presentations in the event.

I would also like to thank all the companies that are making the Summit possible: The Qt Company, Boundary Devices, Intel, ICS, e-Gits, Froglogic, Pelagicore and KDAB. Thank you for helping make Qt Contributors’ Summit special this year!

See you in Oslo!

The post Qt Contributors’ Summit is coming closer appeared first on Qt Blog.

QMetaType knows your types

QMetaType is Qt's way to have run-time dynamic information about your types. It enables things such as QVariant wrapping of custom types, copy of queued connection arguments, and more.

If you ever wondered what does Q_DECLARE_META_TYPE or qRegisterMetaType do and when to use (or not to use) them, read on. This article will describe what you need to know about QMetaType: What is its purpose; How to use it; And how it works.

Why does Qt need runtime dynamic type information?

Let's start with a bit of history. QMetaType was introduced in Qt 4.0. It was created in order to have the possibility to have asynchronous signals and slots (Qt::QueuedConnection). For queued slots to work, we have to copy the arguments and store them in an event that will be processed later. We also need to delete those copies when we are finished invoking the slot. (Note: This is not needed when using Qt::DirectConnection: pointers to arguments directly on the stack are used.)

The code dispatching signals in QMetaObject::activate has an array of pointers to arguments void*. (For more info read how signals and slots work). But, at the time, all Qt knows about the argument types are their name as a string, extracted by moc.

QMetaType provides a way from the string (e.g. "QPoint") to get a to copy or destroy the object. Qt would then use void *QMetaType::create(int type, void *copy) and QMetaType::destroy(int type, void *data) to copy and destroy the arguments, where the int type is obtained using QMetaType::type(const char *typeName) using the type name of the argument, as provided by moc. QMetaType also provides a way for the developer to register any kind of type in the meta type database.

Another use case for QMetaType is QVariant. The QVariant from Qt 3.x only supported built-in Qt types because a contained arbitrary type would also need to be copied or destroyed together with the wrapping QVariant. But with the help of QMetaType, QVariant was able to contain any registered type since QVariant can now copy and destroy contained instances of objects.

What information does QMetaType keep?

Since Qt 4.0 a lot has changed. We now have QtScript and QML which are making intensive use of the dynamic type integration. And we had to optimize a lot.

Here is the list of information kept for each type in the meta-type system:

  • The Type Name as registered. There is a name index for fast lookup of the meta type id. Since Qt 4.7, it is even possible to register the same type with different names (useful for typedefs).
  • (Copy) Constructor and Destructor (in-place or not).
  • Size to know how much space to allocate for a stack or inline member construction.
  • Flags specifying the same information as QTypeInfo (see bellow) or the type of conversion.
  • Custom conversion functions, set by QMetaType::registerConverter.
  • QMetaObject, containing the meta QObject data associated with a type if it exists.

QTypeInfo

QTypeInfo is a trait class orthogonal to QMetaType, it allows the developer to manually specify (using the Q_DECLARE_TYPEINFO) that a type is movable (using memmove) or if its constructor/destructor need to be run. This is mainly used for optimization in containers like QVector.

For example, the implicitly shared classes may be moved with memmove. While a normal copy should first increase the reference count with the copy constructor and then decrease it in the destructor.

C++11 introduces move constructors and standard type traits to solve this problem, but since QTypeInfo was designed way before C++11 and Qt still has to work with older compiler, we have to do without.

How does it work?

For historical reason, there is a big difference between built-in types and custom types. For built-ins types in QtCore, each meta-type function is basically a switch that has special code for each type. In Qt 5.0 this was re-factored to use templates a lot. (See QMetaTypeSwitcher.) But what is going to interest us in this article is how it works for custom registered types.

There is simply a QVector<QCustomTypeInfo> that holds all the information and a bunch of function pointer.

The Q_DECLARE_METATYPE macro.

That macro specializes the template class QMetaTypeId for the specific type. (In fact, it actually specializes the class QMetaTypeId2 and most of the code uses QMetaTypeId2. I don't know the exact reason behind QMetaTypeId2. Maybe so that Qt can add more built-in types without breaking code that used Q_DECLARE_METATYPE before.)

QMetaTypeId is used to determine the meta-type id at compile time for a type.
QMetaTypeId::qt_metatype_id is the function called by the qMetaType<T>(). On the first call of this function, it will call to some internal function within QMetaType to register and allocate a meta-type id for this type, using the name specified in the macro. It will then store that id in a static variable.

Apart from the name, all other information is automatically inferred by the compiler using templates.

qRegisterMetaType

Type registered using Q_DECLARE_METATYPE are going to be actually registered (and be assigned an id) on the first use of qMetaTypeId(). That's the case when a type is wrapped in a QVariant for example. But this is not yet registered when connecting signals and slots. In that case you need to force the first use using qRegisterMetaType

Automatic registration.

Developers often forget to register their meta-type until they see the compilation error or run-time error telling them to do so. But wouldn't it be nice if it would not be necessary? The only reason Q_DECLARE_METATYPE is necessary is to get the name. But there are cases where we can know the name at run-time without that macro. For example, QList<T> if T is already registered, we can query the meta-type system and construct the name using "QList<" + QMetaType::name(qMetaTypeId<T>()) + ">"
We do that for a bunch of templated classes, for example: QList, QVector, QSharedPointer, QPointer, QMap, QHash, ...
We can also determine the name of a pointer to a QObject subclass thanks to the information provided by moc: T::staticMetaObject.className() + "*"
And from Qt 5.5, we will also automatically declare the Q_GADGET and Q_ENUM.

That was it for Q_DECLARE_METATYPE, but you would still need to call qRegisterMetaType to use these type in a Q_PROPERTY or as a parameter in a signal/slot queued connection. Since Qt 5.x however, the code generated by moc will call qRegisterMetaType for you if moc can determine that the type may be registered as a meta-type.

Research

Before Qt 5.0, I was trying to investigate if we would not be able to get rid of Q_DECLARE_METATYPE for cases in which we do not need the name. This worked somehow like this:

 
template<typename T> QMetaTypeId {
    static int qt_metatype_id() {
        static int typeId = QMetaType::registerMetaType(/*...*/);
        return typeId;
    }
};

According to the C++ standard, there shall be exactly one instance of the variable QMetaTypeId::qt_metatype_id()::typeId for each type. But in practice some compilers or linkers do not obey this rule. In particular, on Windows, there would be one instance per library even when using the proper export macro. We would therefore always need a name identifier which we don't have. (And we don't want to rely on RTTI). Therefore we only register the type for which we can know the name in Qt 5.

Qt Quick with the power of OpenCL on Embedded Linux devices

Many Qt users encounter a need to integrate GPU compute solutions into their Qt-based applications. What is more, with the advent of compute API implementations and powerful GPUs on embedded devices, using OpenCL or CUDA on an Embedded Linux device is a reality now. In a previous post we looked at NVIDIA’s Jetson TK1 board and discovered how easy it is to get started with CUDA development in Qt applications using OpenGL. When it comes to OpenCL, developers are not left out in the cold either, thanks to Hardkernel’s ODROID-XU3, where the ARM Mali-T628 graphics processor provides full OpenCL 1.1 support with CL-GL interop in addition to OpenGL ES 3.0.

In this post we will take a look at a simple and powerful approach to integrating Qt Quick applications and OpenCL. We will focus on use cases that involve sharing OpenGL resources like textures or buffers between OpenGL and OpenCL. The examples demonstrate three standard compute use cases and we will see them running on an actual ODROID board.

ODROID-XU3

ODROID-XU3

Why OpenCL and Qt?

The ability to perform complex, highly parallel computations on embedded devices while keeping as much data on the GPU as possible and to visualize the results with Qt Quick and touch-friendly Qt Quick Controls open the door for easily creating embedded systems performing advanced tasks in the domain of computer vision, robotics, image and signal processing, bioinformatics, and all sorts of heavyweight data crunching. As an example, think of gesture recognition: with high resolution webcams, Qt Multimedia, Qt Quick, Qt Quick Controls, and the little framework presented below, applications can focus on the things that matter: the algorithms (OpenCL kernels) performing the core of the work and the C++ counterpart that enqueues these kernels. The rest is taken care of by Qt.

Looking back: Qt OpenCL

OpenCL is not unknown to Qt – once upon a time, back in the Qt 4 days, there used to be a Qt OpenCL module, a research project developed in Brisbane. It used to contain a full 1:1 API wrapper for OpenCL 1.0 and 1.1, and some very helpful classes to get started with CL-GL interop.

Today, with the rapid evolution of the OpenCL API, the availability of an official C++ wrapper, and the upcoming tighter C++ integration approaches like SYCL, we believe there is little need for straightforward Qt-ish wrappers. Applications are encouraged to use the OpenCL C or C++ APIs as they see fit. However, when it comes to the helpers that simplify common tasks like choosing an OpenCL platform and device so that we get interoperability with OpenGL, they turn out to be really handy. Especially when writing cross-platform applications. Case in point: Qt Multimedia 5.5 ships with an OpenCL-based example as presented in the video filters introduction post. The OpenCL initialization boilerplate code in that example is unexpectedly huge. This shows that the need for modern, Qt 5 based equivalents of the old Qt OpenCL classes like QCLContextGL has not gone away. In fact, with the ubiquity of OpenCL and OpenGL on all kinds of devices and platforms, they are more desirable than ever.

Qt 5.5 on the ODROID-XU3

Qt 5.5 introduces support for the board in the device makespec linux-odroid-xu3-g++. Just pass -device odroid-xu3 to configure.

For example, to build release mode binaries with a toolchain borrowed from the Raspberry Pi, assuming a sysroot at ~/odroid/sysroot:

./configure -release -prefix /usr/local -extprefix ~/odroid/sysroot/usr/local -hostprefix ~/odroid/qt5-build -device odroid-xu3 -device-option CROSS_COMPILE=~/odroid/toolchain/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian-x64/bin/arm-linux-gnueabihf- -sysroot ~/odroid/sysroot -nomake examples -nomake tests -opengl es2

This will configure the Qt libraries and target tools like qmlscene to be deployed under /usr/local in the sysroot, while the host tools – like the x86 build of qmake that is to be used when building applications afterwards – get installed into ~/odroid/qt5-build.

When it comes to the platform plugins, both xcb and eglfs are usable, but only one at a time: the Mali graphics driver binary is different for X11 and fbdev, and has to be switched accordingly. The Ubuntu image from Hardkernel comes with X11 in place. While OpenGL is usable under X too, the usage of eglfs and the fbdev drivers is recommended, as usual.

For more information on the intricacies and a step by step guide to deploying Qt on top of the Hardkernel image, see this wiki page. If you have a Mali-based ARM Chromebook featuring a similar CPU-GPU combo, see here.

It is worth noting that thanks to Qt’s Android port, running a full Android system with Qt apps on top is also feasible on this board.

Time for some action

Now to the fun part. Below are three examples running on the framebuffer in full HD resolution with the fbdev Mali driver variant, Qt 5.5 and the eglfs platform plugin. All of them utilize OpenCL 1.1, CL-GL interop, and are regular Qt Quick 2 applications. They all utilize the little example framework which we call Qt Quick CL for now.

OpenGL texture to OpenGL texture via OpenCL

malicl_imageprocess2

An OpenCL-based alternative for ShaderEffect

First, let’s take a look at a standard image processing use case: we will execute one or more OpenCL kernels on our input, which can be a Qt Quick Image element, a (potentially invisible) sub-tree of the scene, or any texture provider, and generate a new texture. With CL-GL interop the data never leaves the GPU: no pixel data is copied between the CPU and the GPU. Those familiar with Qt Quick have likely realized already that this is in fact an OpenCL-based alternative to the built-in, GLSL-based ShaderEffect items.

By using the easy-to-use base classes to automatically and transparently manage OpenCL and CL-GL initialization, and to hide the struggles and gotchas of Qt Quick’s dedicated render thread and OpenGL contexts, the meat of the above application gets reduced to something like the following:

class CLRunnable : public QQuickCLImageRunnable
{
public:
    CLRunnable(QQuickCLItem *item)
        : QQuickCLImageRunnable(item)
    {
        m_clProgram = item->buildProgramFromFile(":/kernels.cl");
        m_clKernel = clCreateKernel(m_clProgram, "Emboss", 0);
    }
    ~CLRunnable() {
        clReleaseKernel(m_clKernel);
        clReleaseProgram(m_clProgram);
    }
    void runKernel(cl_mem inImage, cl_mem outImage, const QSize &size) Q_DECL_OVERRIDE {
        clSetKernelArg(m_clKernel, 0, sizeof(cl_mem), &inImage);
        clSetKernelArg(m_clKernel, 1, sizeof(cl_mem), &outImage);
        const size_t workSize[] = { size_t(size.width()), size_t(size.height()) };
        clEnqueueNDRangeKernel(commandQueue(), m_clKernel, 2, 0, workSize, 0, 0, 0, 0);
    }
private:
    cl_program m_clProgram;
    cl_kernel m_clKernel;
};

class CLItem : public QQuickCLItem
{
    Q_OBJECT
    Q_PROPERTY(QQuickItem *source READ source WRITE setSource)
public:
    CLItem() : m_source(0) { }
    QQuickCLRunnable *createCL() Q_DECL_OVERRIDE { return new CLRunnable(this); }
    QQuickItem *source() const { return m_source; }
    void setSource(QQuickItem *source) { m_source = source; update(); }
private:
    QQuickItem *m_source;
};

...
qmlRegisterType("quickcl.qt.io", 1, 0, "CLItem")
...

import quickcl.qt.io 1.0

Item {
    Item {
        id: src
        layer.enabled: true
        ...
    }
    CLItem {
        id: clItem
        source: src
        ...
    }
}

Needless to say, the application works on a wide variety of platforms. Windows, OS X, Android, and Linux are all good as long as OpenGL (ES) 2.0, OpenCL 1.1 and CL-GL interop are available. Getting started with OpenCL in Qt Quick applications won’t get simpler than this.

OpenGL texture to arbitrary data via OpenCL

CL-GL histogram

Histogram in Qt Quick directly on the GPU

And now something more complex: an image histogram. Histograms are popular with Qt, and the recent improvements in Qt Multimedia introduce the possibility of efficiently calculating live video frame histograms on the GPU.

In this example we take it to the next level: the input is an arbitrary live sub-tree of the Qt Quick scene, while the results of the calculation are visualized with a little Javascript and regular OpenGL-based Qt Quick elements. Those 256 bars on the right are nothing else but standard Rectangle elements. The input image never leaves the GPU, naturally. All this with a few lines of C++ and QML code.

OpenGL vertex buffer generation with OpenCL

VBO generation from OpenCL on the ODROID-XU3

VBO generation from OpenCL

Last but not least, something other than GL textures and CL image objects: buffers! The position of the vertices, that get visualized with GL by drawing points, are written to the vertex buffer using OpenCL. The data is then used from GL as-is, no readbacks and copies are necessary, unlike with Qt Quick’s own GL-based particle systems.

To make it all more exciting, the drawing happens inside a custom QQuickItem that functions similarly to QQuickFramebufferObject. This allows us to mix our CL-generated drawing with the rest of the scene, including Qt Quick Controls when necessary.

Looking forward: Qt Quick CL

QtQuickCL is a small research and demo framework for Qt 5 that enables easily creating Qt Quick items that execute OpenCL kernels and use OpenGL resources as their input or output. The functionality is intentionally minimal but powerful. All the CL-GL interop, including the selection of the correct CL platform and device, is taken care of by the module. The QQuickCLItem – QQuickCLRunnable split in the API ensures easy and safe CL and GL resource management even when Qt Quick’s threaded render loop is in use. Additional convenience is provided for the cases when the input, output or both are OpenGL textures, like for instance the first two of the three examples shown above.

The code, including the three examples shown above, is all available on Gerrit and code.qt.io as a qt-labs repository. The goal is not to provide a full-blown OpenCL framework or wrapper, but rather to serve as a useful example and reference for integrating Qt Quick and OpenCL, and to help getting started with OpenCL development. Happy hacking!

The post Qt Quick with the power of OpenCL on Embedded Linux devices appeared first on Qt Blog.

One Qt Site Unification Completed

Almost a year ago, we started a process to bring the open source web site on qt-project.org and the commercial web pages on qt.digia.com together and thus create one place where all information about Qt could be found. The plans were initially discussed last June with the Qt developer community at the Qt Contributor Summit in Berlin.

The main reasons for starting this project are outlined in my blog post from last August. In short, the split representation of Qt on two unrelated web pages and presenting the same thing as two separate products was hurting both the Free Software Community as well as The Qt Company (or Digia at that time).

A couple of months later, in September we then launched the first phase of the project, the new web site on qt.io. As you know, since then things have gradually evolved, we moved more and more functionality away from both qt.digia.com as well as qt-project.org and into the new and unified web site. Just before Easter we managed to migrate the last of our user facing services over to qt.io.

qt-project.org still contains a few selected services. These are mainly things that are related to contributing to Qt, such as our gerrit. We will discuss further at the next Qt Contributor Summit whether to move them under the qt.io domain as well or not.

While the migration and unification of the existing content to the qt.io web site has now happened, this doesn’t mean that we are done with the work. We are aiming to provide a single sign-on solution through the Qt Account to all our services (forums, wiki, bug reporting, customer portal, etc). This work is still ongoing. Once completed, we believe it’ll greatly improve the experience of using qt.io and all related services. In addition, we are looking into providing additional value with the Qt Account by offering some integration into Qt Creator. We are currently discussing different ideas such as saving and restoring settings, forum and bugtracker integration as well as other items. As we move along with the planning, we will reach out to our users to validate the usefulness of these features and integration. I encourage you to give us feedback on this topic.

The unification project has not only been about our web presence. We have also started working on bringing the open source and commercial versions closer together from a packaging perspective. So far the open source, evaluation and commercial packages have been completely separated, even though there are large overlaps in the content. Bringing those together and having one way to install Qt helps us reduce our workload and thus provide higher quality packages to everybody. We will roll out a new online installer in the coming weeks that will be used to install both commercial (purchased) and open source packages. The new online installer will start asking for a Qt Account login when installing, in order to recognize and present the right license to you and automatically install any commercial/enterprise add-ons that might come with your license.

Apart from the work around the Qt Account and packaging, our work related to the web site will from now on focus on incremental improvements. We would like to invite you all to give us your feedback on how you think we can improve things on qt.io.

I’d like to thank everybody who has been involved in the unification project. A lot of people at The Qt Company have helped with different parts and made sure the whole migration from the old systems went as smoothly as possible. I’d also like to thank all our users for their patience if something wasn’t quite as it should have been and for giving us feedback on where we need to improve.

The post One Qt Site Unification Completed appeared first on Qt Blog.

Qt on the Raspberry Pi 2

The Raspberry Pi 2 computer, released in February 2015, is the latest generation of Raspberry Pi hardware.

It is a significantly faster machine than the original Raspberry Pi, with a new Broadcom BCM2836 system on a chip that has a quad-core ARM Cortex A7 CPU running at 900 MHz. The GPU is a VideoCore IV dual-core GPU, the same as on the original Raspberry Pi.

RAM has been increased from 512 MB to 1 GB, and the number of USB ports from two to four.

Qt on Android Episode 6

In the last Qt on Android episode we learned the basics of JNI on Android in a Qt way. In this episode I’d like to focus on tools that will help us to be more productive when we extend our Qt on Android applications.

Using an external IDE to manage Java files.

Sadly, the Java support in Qt Creator is very limited, and in order to be productive we need to use an external IDE to easily extend and debug the Java part of our application. Android provides two powerful IDEs:

  • Android Studio
  • Eclipse (recently deprecated).

This article will focus only on Android Studio.

But before we talk more about tools, let’s check the Android specific files which are part of your project.

As I told you in the first article, any Qt on Android application has two big parts:

  • The native part, which is your C/C++ [Qt] code built into one or more .so files.
  • The Android specific part:
    • Android manifest file.
    • Android build system file(s).
    • Two Java classes which are needed to load your application dependencies, the application .so files and start the application.
    • Ministro service .aidl files and other resources, e.g. assets, strings, images, etc.

All the Android specific files are needed to build your android package (as we learned in episode 3). But where are all these files? Why are only a few files copied to your sources when you press “Create templates” button (as shown in the next image)? QTC_CopyAndroidTemplates_o

Well, Java, Ministro service .aidl files and some resources are kept “hidden” in your Qt SDK. We don’t want to copy them to your source tree for two reasons:

  • We might change them from version to version and we might break the compatibility. If they are part of your project it will be impossible to upgrade them and your application will misbehave (e.g. Java files from Qt 5.4 might not be compatible with Qt 5.5).
  • We don’t want you to change them, because the code in these files is quite sensible, hard to explain and understand and changing them might break your application behavior. If you should not change them, then all your applications will share the same files, so again there is no point in copying them :).

Before Qt 5.4 it was quite complicated to extend the Java part of your application, mostly because you could not use an external IDE (Eclipse) in a decent way (e.g. with syntax highlighting, code-completion, code-refactoring, etc.). In order to get these goodies you had to manually copy all the Java files from Qt SDK installation folder to your application source folder, but as I said, we don’t want you to do that and the only way to do it was to copy them locally and not add them to your SCM…

But starting with Qt 5.4. the situation changed when I added Gradle support to Qt 5.4 and to Qt Creator 3.3. Gradle is the new recommended android build system which is used by Android Studio. Using Gradle we can keep all these files hidden and still give you all the goodies that you expect from a 21st century IDE. So, if you are planning to extend your Java part of your application, it is highly recommended to Copy the Gradle files to Android directory as shown in the next image: QTC_CopyAndroidTemplatesCopyGradle_o

Besides the AndroidManifest.xml and res/values/libs.xml files, the wizard will copy a few more:

  • build.gradle – this is the project file needed by Android Studio.
  • gradlew[.bat] – build script wrapper used to build Java part and to create final APK.
  • gradle/wrapper/* – build script wrapper files

build.gradle is very important, it allows you to easily add dependencies to your project.

E.g. to add PlayServices to your application you just need to add:

dependencies {
    ...
    compile 'com.google.android.gms:play-services:7.0.0'
}

to build.gradle, check this page for more info on this matter.

Now let’s see how to use Android Studio with Qt:

Android Studio will be used only to:

  • open the Gradle project.
  • create, edit the java files.
  • debug the Java part.

Android Studio will NOT be used to run your Qt application, you still need to use Qt Creator for that job!

Let’s take a look on how to import the Java part of your Qt application and how to debug it.

The import step is very easy: you just need to Open the existing build.gradle project file. Check the following image: AndroidStudio_OpenProject_o

Warning: Qt 5.4.0 users should upgrade their gradle files using Qt 5.4.1 or later (press again Create templates button and overwrite only gradle files). This step is needed because Qt 5.4.0 uses an old Gradle plugin and, after we released it, Google, as usual, broke the compatibility with older Gradle plugins and Android Studio doesn’t import Qt 5.4.0 projects.

The last thing we are going to learn today is how to debug the Java part using Android Studio. You need to take the following steps:

  • set the breakpoints
  • attach debugger (Run->Attach debugger to Android process)
  • start the application using QtCreator
  • wait for application to start (you should see it in Attach debugger dialog).
  • select the application
  • click the OK button

After the last step, your application will be stopped by Android Studio when it hits first breakpoint.The problem comes when we need to start the debugging very early. To do that we are going to use the old fashioned sleep trick Debug.waitForDebugger() function.

This is how our custom onCreate function looks:

@Override
public void onCreate(Bundle savedInstanceState)
{
    Debug.waitForDebugger();
    // ....
    super.onCreate(savedInstanceState);
}

Now the application waits until a debugger attaches, then in resumes the execution.

Now that we have learned the basics of the JNI and how to use external tools to make la vie en rose (or la dolce vita), in the next article we will talk about Qt on Android apps architecture: how to extend the Java part of your application using a real life example to show how to correctly do safe calls from Qt thread to Android UI thread and vice-versa.

The post Qt on Android Episode 6 appeared first on KDAB.

Effective Surge Strategy

At some point in any extended-length development project -- whether it’s a multi-year project or a multi-month project -- you’re going to need what I’m calling a Surge. What’s going to prompt a Surge?

Here are some examples:

Some Lesser Known Qt Tools and Commands - Part 2

Continuing with our series of blog posts on some of the lesser known Qt commands, this time we will look at some tools related to Qt and D-Bus.

D-Bus (1) is an inter-process communication (IPC) system that allows multiple concurrently running computer programs to communicate.

Qt Installer Framework 2.0 Released

We’re happy to announce version 2.0 of the Qt Installer Framework.

The Qt Installer Framework is a set of tools to provide offline and online installers on Windows, Linux, and OS X. It’s focused on the requirements of the Qt installers, but is flexible enough to be used as an installer and updater for other applications, too. See the documentation for an overview of its features. The Tutorial section shows you how to create a simple offline installer.

Version 2.0 contains a whole lot of bug fixes and new features: See the ChangeLog for the full picture. The reason to bump the major version number is, however, that the framework itself is now built with Qt 5 instead of Qt 4. Among other things, the scripting backend has been ported from Qt Script to the Qt QML module, while maintaining full compatibility for the scripts. The port to Qt 5 also allows you to run fully scripted installers without any GUI.

We have been striving to keep compatibility for existing 1.6 installations. That is, you should be able to update existing 1.x online installers transparently with ones built with 2.0.

You can find precompiled and source packages in your Qt Account and on qt.io.

Special thanks go to Christoph Vogtländer, Sze Howe Koh, Ray Donnelly, Tasuku Suzuki, Takayuki Orito, Sascha Cunz, Zhang Xingtao, Sergey Belyashov and Cuoghi Massimiliano for contributions.

The post Qt Installer Framework 2.0 Released appeared first on Qt Blog.

Brace Yourself ‐ Qt World Summit 2015 Call for Papers is Coming!

by Nils Christian Roscher-Nielsen (Qt Blog)

Last month we announced that this October 6-7 we will be hosting the Qt World Summit in Berlin – the global event for all things Qt!

The big themes for the whole Qt World Summit are:

  • Creating connected devices and Internet of Things systems
  • Qt as the software solution for multi-platform development – desktop, mobile and embedded
  • Industrial and automotive HMI trends
  • Multiscreen development strategies
  • Creation of modern desktop user interfaces
  • And of course the Qt offering, latest features and product roadmap!

We are progressing nicely with the preparations and as part of that, we are of course building the best possible agenda. Naturally, a big part of that comes from the high-quality talks delivered by Qt developers, contributors, all the members of the Qt community, and the related industries. This is where you come in, folks:

Later this month we will be opening the Call for Papers for everyone to submit their ideas for talks. This is your unique opportunity to get to speak at the #1 Qt event of the year, on your topic. The call for papers will be closed around the end of May. So this is a heads-up to already to start thinking now about what you might like to present at the summit!

We will be opening up for proposals in two main categories: Qt in Use talks and developer focused talks. We encourage those who can to submit two talks covering the same topic: one being more use case oriented and the other a hands-on live coding demonstration. More information on this coming with the call for papers!

We will ask that your proposals will be submitted as abstracts. Our program committee consisting of The Qt Company and Qt Partner members will then select the presentations for the event.

The official call for papers will be announced formally with all the details provided on the event site: www.qtworldsummit.com.

qtws15

The post Brace Yourself ‐ Qt World Summit 2015 Call for Papers is Coming! appeared first on Qt Blog.

Parsing Emacs OrgMode files, EU patent debate, and vacation!

After starting the year with two rather busy months, I planned to take it easy a bit. Such an optimistic plan of course never works out as intended… In times like these, it really helps that I love my job(s). It included a trip to Brussels to present the Open Source perspective on the role of patents at the European Commission Joint Research Center. Between office hunting and strategy workshops, there was also some time to hack on the OrgModeParser! See below.

I already mentioned earlier the plans to present about the situation of the Open Source community as a consumer of the patent system at the conference on “Innovation in a European Digital Single Market – The Role of Patents” in Brussels on March 17. FSFE, OpenForum Europe, colleagues at OIN and fellow Open Source supporters provided great feedback for the presentation. Many thanks to everybody who contributed! In the end, the concept for the presentation (which was a short introduction to a following panel discussion) was to explain five concrete difficulties the patent system causes in a collaborative production environment. The slides are available on the conference site. I hope to find some time to write up the presentation in a future blog post.

Sage joined the Open Invention Network. OIN is the world’s largest patent non-aggression community with the mission to protect Linux and Open Source. It speaks for the credibility that patent non-aggression has achieved and for how OIN represents that idea in the Open Source space when a publicly listed company that grew to success long before Linux really took off subscribes to it. Thanks, Sage! More large and small companies are considering this step. Your company should do so, too. If you have any questions, feel free to contact me.

The Endocode office hunt continues. We visited quite a number of available spaces, but the market is contested and suitable space is hard to come by. We are trying to have everybody involved have a say in the choice, too. This naturally leads to some quite lively discussions. An essential goal is to create a space that serves well as the home of the creative productivity our team enjoys. This includes flexible ways of working together, a mix of functional and motivational (read: fun) requirements, and generally an inviting atmosphere that one can look forward to when getting up in the morning. I think it is worth it to be picky. Hopefully we can invite for an office warming party soon…

We also continued with our series of Endocode strategy workshops. Our work revolves around Open Source form different angles – software engineering, DevOps and contributor relations. Analysing these different fields to identify a value chain that ties them all together is in a way intuitive for us that “grew up” in communities, but there is a significant gap in understandings and values from a business strategy perspective. But there must be a way, considering that Open Source is in essence a coordination mechanism for collaborative production, which is in turn a purely economic concept. We are making good progress, but I do expect it to still take significantly more effort. Still, such thought experiments are rather engaging and a great challenge to be part of.

Then, finally, I found some time to hack on a fun project of mine (woohoo!) A while ago I came up with the completely insane idea to access the content of Emacs OrgMode files from independent programs. Emacs OrgMode is hands-down about the best tool for the collection of notes, ideas, tasks, for tracking time, for writing content, and so much more. Nobody would ever argue about that :-) I wanted to be able to read OrgMode files in the programs I write, which are usually implemented in C++ and Qt. The code of OrgModeParser is on Github and LPGL 3 licensed. This week, this yielded a first working version and a demo program that integrates clocked work time data into the bash prompt:

clock-time-demo.png

The yellow line in the screenshot is the output of the OrgModeParser clock time demo, embedded into the bash prompt. It shows the currently clocked task, the running time of the current session, and on the right side of the screen the time clocked today and this week. One curiosity that triggered this was the inclusion of lambda functions into C++ with the recent updates of the language standard. There were quite a number of discussions of how the new C++ better supports functional programming approaches and is closer to some concepts of scripting languages, which I wanted to try out. It leads to some really interesting code:

ClockTimeSummary.cpp

//Find all clocklines that are incomplete (not closed):
auto const notCompleted = [](const ClockLine::Pointer& element) {
    return element.dynamicCast<CompletedClockLine>() == 0;
};
auto clocklines = findElements<ClockLine>(toplevel_, -1, notCompleted);
//Sort by start time, to determine the latest task that was started:
auto const startedLater = [](const ClockLine::Pointer& left, const ClockLine::Pointer& right) {
    return left->startTime() > right->startTime();
};
sort(clocklines.begin(), clocklines.end(), startedLater);

This finds all started, but not completed clock lines in an OrgMode file and sorts them by the start time with the last clocked-in task first in the list. Lambdas and automatic typing are a huge step forward in readability, and also from a practical point of view: The compiler prevents many mistakes, and of course a breakpoint can be set in the body of a lambda function. Good stuff, and the parser is fast enough to process a 100kByte TODO list in mere milliseconds, so it can be integrated into a typical bash prompt like this:

.bashrc

PS1="$PS1\$(OrgModeParser_ClockTimeDemo -p -c\${COLUMNS} ~/Org/TODO.org)\n"

The code builds and install with CMake and should compile on any recent Linux distribution or OSX installation. It requires Qt 5. I haven’t tried building it on Windows. If you are like me and occasionally (ahem :-) ) forget to clock into the task you currently work on, this may be of help. It is however meant to be a demo of what the parser can do: load an OrgMode file into a data structure that can be queried or filtered, updated and saved out again. Potential applications include embedding OrgMode data into GUI applications, or creating or reading TODO or CLOCK entries from other external tools like time trackers. Or even, which is one of the main long term motivations, enable integration with online project management tools like Redmine.

Next week I will be on a family vacation, which includes being offline. Offline as in no internet, no power outlets, and most of the time not even a hint of phone reception. I am so looking forward to it. I will check back in on April 13. Happy Easter holidays!

IMG_20140417_175713.png

Filed under: Coding, CreativeDestruction, English, FLOSS, KDE, OSS, Qt

Qt Creator 3.4 RC1 released

We are happy to announce the release of Qt Creator 3.4 RC1 today.

I already described many of the new features in the beta blog post. Since then, we fixed many bugs, including a whole lot of debugger integration issues, and generally polished Qt Creator for release. You find the more complete change log at code.qt.io.

Now we think that we are almost ready for a final 3.4 release, so this is a great time for you to get the package, try it, and give us some last minute feedback on our bug tracker, on the Qt Creator mailing list, or on IRC on #qt-creator on irc.freenode.net.

You find the opensource version on the Qt Project download page, and Enterprise packages on the Qt Account Portal.

The post Qt Creator 3.4 RC1 released appeared first on Qt Blog.

Qt Quick Controls for Embedded

Qt Quick Controls are a set of styled UI controls to conveniently build user interfaces in QML. The first release of Qt Quick Controls was included in Qt 5.1 and targeted desktop platforms. Subsequent releases have also vastly improved the support for mobile platforms.

Qt Quick Controls are not only offered for convenience, but also act as an example to vendors wanting to create their own UI control sets. Unlike specialized control sets for a defined target platform, Qt Quick Controls have a broad scope from desktop to mobile and embedded. This has led to a flexible, but somewhat complex design.

When targeting embedded hardware with limited resources, we would like to offer better performance than what the current set of Qt Quick Controls provide. Over the past months, we have spent a great deal of time researching, profiling, and discussing alternative approaches. We would like our customers to enjoy the convenience of Qt Quick Controls everywhere without a significant performance impact.

We now have a promising prototype up and running, so we thought it would be a good time to share the status. We have posted a little sneak preview showing the new controls in action. Please notice that the visual appearance is not final.

The following sections highlight some of the ideas that together helped to achieve a remarkable performance boost.

QML vs. C++

In many cases, the internal state of a control can be more efficiently processed in C++. For example, handling input events in C++ makes a difference for controls that would otherwise need to create internal MouseAreas and attached Keys objects. By doing all the heavy-lifting in C++, the visual QML layer could be implemented using simple and efficient declarative bindings.

The following charts present creation times of various Qt Quick Controls compared to what we have now in the works.

qqc-i7-1

qqc-rpi-1

As you can see, on a device like RPi, one still cannot create too many controls per frame when aiming for 60 FPS scrolling. We are clearly headed the right direction, though. :)

Styles

The new controls are spiced up with a customizable, light-weight and platform independent Qt style that performs well on devices with limited resources. The concept of styling is changing in a way that styles no longer provide components that are dynamically instantiated by controls, but controls themselves consist of delegates that can be replaced without dynamic instantiation. Style objects on the other hand have become simple sets of styling attributes. In order to brand an application, changing the color scheme is a matter of setting a few properties that are automatically inherited by the hierarchy of children.

Keep things simple

When it comes to more complex compound controls, it is sometimes better to provide the sub-controls as separate building blocks. As an example, we consider replacing the complex ScrollView control by simple ScrollBar/Indicator controls that can be attached to any Flickable:

ScrollView {
    horizontalScrollBarPolicy: Qt.ScrollBarAlwaysOff
    Flickable {
        ...
    }
}

// vs.

Flickable {
    ...
    ScrollBar.vertical: ScrollBar { }
}

Maybe not entirely fair to compare these two approaches, but here’s the gain of the oversimplification in numbers:

qqc-i7-2

qqc-rpi-2

Wrap up

We have been exploring a bit what it would take to bring Qt Quick Controls to the segment of devices with limited resources. Some ideas, leading to significant performance improvements, are presented above. The performance comparisons focus on creation time, which reflects directly to application startup time, loading time of application views, and scrolling speed of item views that create and destroy delegate instances while scrolling. Simplifying things and doing all the heavy-lifting in C++ reduces memory consumption as well. Currently a Button using the “Base” style consists of 17 Items (of which 4 are Loaders) and a total of 64 QObjects. The amount of Items of a Button is now down to 3, and the total amount of QObjects is 7 at the moment.

Please bear in mind that the new light-weight controls are still in early development. The numbers, visual appearance, and the whole concept are still subject to change.

EDIT: The source code is available at http://code.qt.io/cgit/qt-labs/qtquickcontrols2.git.

The post Qt Quick Controls for Embedded appeared first on Qt Blog.

C++11/C++14 Training Sold Out! New one in May!

KDAB’s popular 3 day Training course: What’s new in C++11/C++14 training has SOLD OUT in April but don’t despair, you can still get up to speed with the new language for better productivity and performance in your project.

KDAB’s Thomas McGuire is putting on bonus session just for you: 11th – 13th May, at our training facility in Berlin, Germany.

Register now! Training for professional C++ developers

This KDAB training has features such as improved lambas with lambda init capture and generic lambdas, relaxed constexpr, variable templates, improved return type deduction, binary literals, digit separators, a deprecated attribute, decltype(auto) and some library additions in places like iterators, algorithms, literals, type traits and more.

The course also offers optional advanced C++11/14 features like variadic templates and perfect forwarding. All our training material is clearly marked for C++14 improvements you can choose to ignore if you work with C++11.

Read more…

The post C++11/C++14 Training Sold Out! New one in May! appeared first on KDAB.

qt-project.org to redirect to qt.io/developers

We are happy to announce that our “One Qt” unification project will soon reach its major milestone. On April 1, we will redirect the remaining pages to qt.io. qt-project.org will redirect to qt.io/developers.

If you have been following our progress, you know that the forums have already been redirected since their migration a couple of weeks ago, as well as the documentation. Both services are working well in their new homes.

The last major user service that the redirects will impact is the Qt Wiki. The new wiki has now been open for almost a month, and it has been adopted well by the community. It has seen clearly more activity than the old wiki, as the platform is more familiar to everyone, making it more approachable and familiar to use.

Some of the services in qt.io will require Qt Account credentials for logging in. Both the Qt Wiki and Qt Forum use Qt Account as their login service and we are planning to introduce more services and benefits to Qt Account in the near future.

If you are wondering what happens to the username you had on qt-project.org, it has been reserved for your e-mail address in Qt Account. When you create a Qt Account, please do it with the same e-mail address as you used on qt-project.org, that way you can connect to your old forum information.

It is important to note that while the services for users of Qt are being unified under the qt.io domain, the resources for developing Qt itself are staying in the qt-project.org domain. The codereview with it’s repositories will still be at codereview.qt-project.org and the mailing lists are staying at lists.qt-project.org.

For the next phase of improving our developer pages, we would like to hear from you what the homepage of qt.io/developers should look like. We will be updating that page to include information, links and whatever you feel is needed. Please share your thoughts via this thread in the Qt Forum.

As this has been an incremental project together with the community, we have received lots of feedback that have helped this project go as smooth as possible. Naturally, there will be some things that won’t be exactly as they were on qt-project.org and DevNet, however, as we move into maintenance phase, we will also add improvements and new programs that will benefit you.

We thank you for your support in working with us to make this a smooth transition and believing in the “One Qt” initiative. We also thank  the qt-project.org and DevNet site, which established the first digital global home for our ecosystem. We don’t want to say “good bye” to qt-project.org nor to DevNet, but “See ya” as we welcome it into qt.io and our unified ecosystem.

As always, we appreciate any feedback you have.

The post qt-project.org to redirect to qt.io/developers appeared first on Qt Blog.

The current state of Windows Embedded Compact (WEC) platform support in Qt

by Björn Breitmeyer

It has been very quiet around WEC platform support in Qt, and you would have been forgiven for thinking that nothing was happening. But behind the scenes, we have been tackling some pretty hard issues. We just did not blog about the ongoing work….until now.

Be assured that the platform is still maintained and there is work happening. Here is a short overview of the work my co-worker at KDAB, Andreas Holzammer and myself have done on the WEC support.

Qt Multimedia Qt Multimedia is still listed as a not supported module for WEC. This has changed slightly as we reintroduced the ability to playback audio files based on the DirectShow backend: https://codereview.qt-project.org/#/c/93093/.

Read more…

The post The current state of Windows Embedded Compact (WEC) platform support in Qt appeared first on KDAB.

Qt Developer Days Videos and passing the torch

For the past three years, KDAB has had the honor and pleasure to bring you the European Qt Developer Days Conference in Berlin. Now it’s time to pass the torch and, we’d like to offer you a farewell gift:

Watch the videos!
Videos from the 2014 Qt Developer Days Europe are now online along with videos and slides from 2013 and 2013 – all at a single location. Enjoy! And thanks for the ride.

Last month The Qt Company announced the Qt World Summit, to be held again in Berlin at the bcc Berlin Congress Centre. RIP Qt Developer Days, Welcome to the Qt World Summit!

Read the back story from KDAB’s Chief Executive, Kalle Dalheimer here…

The post Qt Developer Days Videos and passing the torch appeared first on KDAB.