New and improved Inqlude web site

During last year's Summer of Code I had the honor of mentoring Nanduni Indeewaree Nimalsiri. She worked on Inqlude, the comprehensive archive of third party Qt libraries, improving the tooling to create a better structured web site with additional features such as categorization by topic. She did an excellent job with it and all of her code ended up on the master branch. But we hadn't yet made the switch to change the default layout of the web site to fully take advantage of all her work. As part of SUSE's 15th Hack Week, which is taking place this week, I took some time to change that, put up some finishing touches, and switch the Inqlude web site to the new layout. So here we are. I proudly present the new improved home page of Inqlude.


All libraries have additional meta data now to group them by a number of curated topics. You can see the topics in the navigation bar on the left and use them to navigate Inqlude by categories. The listing shows more information on first view, such as the supported platforms, to make it easier to find libraries according to your criteria without having to navigate between different pages. The presentation in general is cleaner now, and some usability testing has shown that the page works better now than before. In addition to the visible changes, Nanduni has also done quite a bit of improvements under the hood, including better automated testing. I'm proud of what we have achieved there.

It always has been a privilege for me to act as mentor as part of Google's Summer of Code or other programs. This is one of the most rewarding parts of working in free software communities, to see how new people learn and grow, especially if they decide to stay involved after the program has ended and become valuable members of the community for the long term. Being able to help with that I feel is one of the most satisfying investments of your time in the community.

Building the latest greatest for Android AArch64 (with Vulkan teaser)

Let’s say you got a 64-bit ARM device running Android. For instance, the Tegra X1-based NVIDIA Shield TV. Now, let’s say you are also interested in the latest greatest content from the dev branch, for example to try out some upcoming Vulkan enablers from here and here, and want to see all this running on the big screen with Android TV. How do we get Qt, or at least the basic modules like QtGui, QtQuick, etc. up and running on there?

nv_shield_2017 Our test device.

In this little guide we are going to build qtbase for Android targeting AArch64 and will deploy some examples to the Android TV device. To make it more interesting, we will do this from Windows.

Pre-requisites

The Qt documentation and wiki pages document the process fairly well. One thing to note is that a sufficient MinGW toolchain is easily obtainable by installing the official 32-bit MinGW package from Qt 5.8. Visual Studio is not sufficient as of today.

Once MinGW, Perl, git, Java, Ant, the Android SDK, and the 32-bit Android NDK are installed, open a Qt MinGW command prompt and set some environment variables:

set PATH=c:\android\tools;c:\android\platform-tools;
  c:\android\android-ndk-r13b;c:\android\qtbase\bin;
  C:\Program Files\Java\jdk1.8.0_121\bin;
  c:\android\ant\bin;%PATH%
set ANDROID_API_VERSION=android-24
set ANDROID_SDK_ROOT=c:\android
set ANDROID_BUILD_TOOLS_REVISION=25.0.2

Adapt the paths as necessary. Here we assume that the Android SDK is in c:\android, the NDK in android-ndk-r13b, qtbase/dev is checked out to c:\android\qtbase, etc.

The Shield TV has Android 7.0 and the API level is 24. This is great for trying out Vulkan in particular since the level 24 NDK comes with the Vulkan headers, unlike level 23.

Build qtbase

Now the fun part: configure. Note that architecture.

configure -developer-build -release -platform win32-g++
  -xplatform android-g++ -android-arch arm64-v8a
  -android-ndk c:/android/android-ndk-r13b -android-sdk c:/android
  -android-ndk-host windows -android-ndk-platform android-24
  -android-toolchain-version 4.9 -opensource -confirm-license
  -nomake tests -nomake examples -v

Once this succeeds, check the output to see if the necessary features (Vulkan in this case) are enabled.

Then build with mingw32-make -j8 or similar.

Deploying

To get androiddeployqt, check out the qttools repo, go to src/androiddeployqt and do qmake and mingw32-make. The result is a host (x86) build of the tool in qtbase/bin.

For general information on androiddeployqt usage, check the documentation.

Here we will also rely on Ant. This means that Ant must either be in the PATH, as shown above, or the location must be provided to androiddeployqt via the –ant parameter.

Now, Qt 5.8.0 and earlier have a small issue with AArch64 Android deployments. Therefore, grab the patch from Gerrit and apply on top of your qtbase tree if it is not there already. (it may or may not have made its way to the dev branch via merges yet)

After this one can simply go to a Qt application, for instance qtbase/examples/opengl/qopenglwidget and do:

qmake
mingw32-make install INSTALL_ROOT=bld
androiddeployqt --output bld
adb install -r bld/bin/QtApp-debug.apk

Launching

Now that a Qt application is installed, let’s launch it.

Except that it does not show up in the Android TV launcher.

One easy workaround could be to adb shell and do something like the following:

am start -n org.qtproject.example.qopenglwidget/org.qtproject.qt5.android.bindings.QtActivity

Then again, it would be nice to get something like this:

nv_shield_qopenglwidget_launcher

Therefore, let’s edit bld/AndroidManifest.xml:

<intent-filter>
  <action android:name="android.intent.action.MAIN"/>
  <!--<category android:name="android.intent.category.LAUNCHER"/>-->
  <category android:name="android.intent.category.LEANBACK_LAUNCHER" />
</intent-filter>

and reinstall by running ant debug install. Changing the category name does the trick.

Note that rerunning androiddeployqt overwrites the manifest file. A more reusable alternative would be to make a copy of the template, change it, and use ANDROID_PACKAGE_SOURCE_DIR.

The result

Widget applications, including OpenGL, run fairly well:

nv_shield_qopenglwidget

Or something more exciting:

qqvk_shield_1

No, really. That clear to green is actually done via Vulkan.

qt_vk_android_texture

And finally, the hellovulkantexture example using QVulkanWindow! (yeah, colors are a bit bad on these photos)

adb logcat is your friend, as usual. Let’s get some proof that our textured quad is indeed drawn via Vulkan:

qt.vulkan: Vulkan init (libvulkan.so)         
vulkan  : searching for layers in '/data/app/org.qtproject.example.hellovulkantexture-2/lib/arm64'     
...
qt.vulkan: Supported Vulkan instance layers: QVector()              
qt.vulkan: Supported Vulkan instance extensions: QVector(QVulkanExtension("VK_KHR_surface" 25), QVulkanExtension("VK_KHR_android_surface" 6), QVulkanExtension("VK_EXT_debug_report" 2))    
qt.vulkan: Enabling Vulkan instance layers: ()                                                                                            
qt.vulkan: Enabling Vulkan instance extensions: ("VK_EXT_debug_report", "VK_KHR_surface", "VK_KHR_android_surface")                     
qt.vulkan: QVulkanWindow init                                                                                                        
qt.vulkan: 1 physical devices                                                                                                              
qt.vulkan: Physical device [0]: name 'NVIDIA Tegra X1' version 361.0.0                                                                     
qt.vulkan: Using physical device [0]                                                                                                      
qt.vulkan: queue family 0: flags=0xf count=16                                                                                                               
qt.vulkan: Supported device layers: QVector()                                                                                      
qt.vulkan: Enabling device layers: QVector()                                                                                       
qt.vulkan: Supported device extensions: QVector(QVulkanExtension("VK_KHR_swapchain" 68), QVulkanExtension("VK_KHR_sampler_mirror_clamp_to_edge" 1), QVulkanExtension("VK_NV_dedicated_allocation" 1), QVulkanExtension("VK_NV_glsl_shader" 1))                                                                                
qt.vulkan: Enabling device extensions: QVector(VK_KHR_swapchain)                                                     
qt.vulkan: memtype 0: flags=0x1                                                 
qt.vulkan: memtype 1: flags=0x1                           
qt.vulkan: memtype 2: flags=0x7                             
qt.vulkan: memtype 3: flags=0xb                               
qt.vulkan: Picked memtype 2 for host visible memory             
qt.vulkan: Picked memtype 0 for device local memory     
initResources            
uniform buffer offset alignment is 256        
qt.vulkan: Creating new swap chain of 2 buffers, size 1920x1080       
qt.vulkan: Actual swap chain buffer count: 2                
qt.vulkan: Allocating 8847360 bytes for depth-stencil        
initSwapChainResources              
...

Should you need validation layers, follow the instructions from the Android Vulkan docs and rebuild and redeploy the package after copying the libVkLayer* to the right location.

That’s all for now. Have fun experimenting. The basic Vulkan enablers, including QVulkanWindow are currently scheduled for Qt 5.10, with support for Windows, Linux/X11, and Android. (the list may grow later on)

The post Building the latest greatest for Android AArch64 (with Vulkan teaser) appeared first on Qt Blog.

foss-north 2017

After much preparation, the tickets for foss-north 2017 is available at foss-north.se – grab them while they are hot!

The call for papers is still open (do you want to talk – register!) so we do not have a final schedule, but you will find our confirmed speakers on the web site as we grow the list. Right now, we know that have the pleasure to introduce:

  • Lydia Pintscher, the product manager of Wikidata, Wikimedia’s knowledge base, as well as the president of KDE e.V.
  • Lennart Poettering, from Red Hat known for systemd, PulseAudio, Avahi and more.
  • Jos Poortvliet, with a background from SUSE and KDE, he now heads marketing at Nextcloud.

The conference covering both software and hardware from the technical perspective. The event is held on April 26 in central Gothenburg located between Copenhagen, Oslo and Stockholm with an international airport.

This is a great excuse to visit a really nice part of Sweden while attending a nice conference – welcome!

Qt 5.9 Alpha Released

I am happy to inform you that Qt 5.9 Alpha has been released today.

Qt 5.9 Alpha is an important milestone on our way to the final Qt 5.9.0 release, which is targeted to be released by the end of May 2017.

The Alpha release is available only as source packages. Binary installers will be available via the online installer in conjunction with the Beta release as well as development snapshots during the coming weeks.

To learn about the features in Qt 5.9, please read the Qt 5.9 new features page. For more detailed overview of some Qt 5.9 key features, check the Qt Roadmap for 2017 blog post.

If you want to try Qt 5.9, please download the Qt 5.9 Alpha source packages from your Qt Account or from download.qt.io.

Please remember to give us feedback by writing to the mailing lists and reporting bugs.

The post Qt 5.9 Alpha Released appeared first on Qt Blog.

Qt Quick WebGL Streaming

WebGL Streaming is optimized for Qt Quick and allows you to run remote Qt Quick applications in a browser.

I’m working on a platform plugin to run remote applications in your browser, using OpenGL command streaming.

When the remote application runs using this new platform plugin, the application will create a lightweight web server. When a user connects to the application, a web socket connection is opened between the server and the client, using QWebSocketServer.
The application running on a remote computer will serialize all GL calls to binary data and sends it using the web socket connection.

The local browser will send the event (mouse, touch or keyboard) to the remote application, so user interaction is allowed. Even multi-touch support! (up to 6 fingers):

And some Qt Quick demos running in the browser:

The “calqlatr” example:

“clocks” example:

“emitters” (particles) example:

“samegame” example:

Desktop browsers are also supported:
webgldemo

It allows multiple connections to the same application.

screenshot_20170222_183836

New windows are shown in a different canvas in the browser.screenshot_20170222_184419

To improve the performance, I’m also working to support web sockets compression. To be able to use the permessage-deflate extension. It’s actually working but needs more testing.

This feature is going to be introduced in Qt 5.10 as appears in the 2017 roadmap.

The post Qt Quick WebGL Streaming appeared first on Qt Blog.

Qt Roadmap for 2017

With Qt 5.7 and 5.8 released we have a completely new baseline for Qt 5 based applications and devices. In this blog, I want to provide a roadmap update on what we are currently working on in the Qt R&D and what the future directions are.

About a year ago I provided a roadmap update for 2016. Looking back the past year, I am very happy and proud that we have been able to develop and deliver all those great features and improvements. I would like to thank each and every Qt developer for their input. While most of the functionality is created by The Qt Company, we also have many community contributors who have provided multiple extremely valuable contributions throughout the years. In addition to those contributing code, we have also a large number of people active in the Qt Project forums, on mailing lists, as well as reviewing code and testing the Qt development releases. Together we create the Qt framework. Thanks!

Release Timelines

Throughout the lifetime of Qt 5 we have been steadily providing a new feature release of Qt every six months. While it has taken a bit longer than anticipated to release some versions, we have been able to keep this heartbeat steadily. Our plan is to continue to do so in the future. Therefore, after Qt 5.8 we will release Qt 5.9, Qt 5.10 and Qt 5.11 with roughly six month intervals.

Despite Qt 5.8 just being released, we already have the features of Qt 5.9 frozen and the alpha release will be available very soon. For those interested in taking a closer look into Qt 5.9 features, please check out the New Features of Qt 5.9 wiki page. Our target is to release Qt 5.9 in May 2017. Parallel to finalization of Qt 5.9, the development of Qt 5.10 is ongoing. Everything that is merged now to the dev branch of Qt is to become part of the Qt 5.10 release planned for November 2017. After Qt 5.10 is branched from dev, development of Qt 5.11 starts with planned release in May 2018.

New Features in Qt 5.9

Qt 3D was first released with Qt 5.7 and in Qt 5.8 the focus was mostly on stability and performance. With Qt 5.9 we are providing many new features which significantly improve the functionality of Qt 3D. Notable new features include support for mesh morphing and keyframe animations, using Qt Quick items as a texture for 3D elements, as well as support for physically based rendering and particles. There are also multiple smaller features and improvements throughout the Qt 3D module.

We are continuously focusing into improving graphics performance and Qt 5.9 brings new graphics features focusing especially on performance optimization. Applications utilizing OpenGL shaders will benefit from new shader disk cache, which will significantly reduce the initialization time of OpenGL shaders. With our measurements we have seen up to 10x improvement in shader performance compared to Qt 5.6 and up to 8x improvement compared to Qt 5.8 in some commonly used embedded devices. Other graphics related improvements in Qt 5.9 include sharing of resources such as bitmaps between processes reducing memory consumption in multiprocess systems, support for Wayland XDG Shell version 6 and support for Wayland IVI extensions.

On the QML engine side we introduced a major new approach with Qt 5.8: a disk cache for the just-in-time compiled QML and JavaScript. The work will continue towards introducing a completely re-implemented Qt Quick Compiler for ahead-of-time compilation of QML and JavaScript. Qt 5.9 offers the commercial-only ahead-of-time compilation with Qt Quick Compiler and the binary cache for just-in-time compiled QML to commercial and open-source users, just like Qt 5.8. In addition, Qt 5.9 provides a preview of a new ahead-of-time cache generation, which we aim to develop further for the Qt 5.10 release. The new approach is intended to replace the earlier Qt Quick Compiler with similar or improved performance on all supported platforms. For Qt 5.9, we are providing also some further improvements in the QML engine. Most notably the completely rewritten garbage collector offers a base line for improved speed and reduced memory consumption of future Qt Quick applications.

We have further tuned Qt Quick Controls functionality and added many new features improving the usage across desktop, mobile and embedded platforms. With Qt 5.9 we are adding ScrollView, an editable ComboBox and multi-touch support, to name a few of the most interesting new features. The new ScrollView provides flicking and non-interactive scroll indicators on touch and switches to interactive scroll bars when interacted with a mouse pointer. The editable ComboBox allows typing in auto-completed values using keyboard and multi-touch support allows interacting with multiple buttons and sliders at the same time.

Qt Network and especially QNetworkAccessManager (QNAM) have been improved in Qt 5.9. Previously, the behavior when encountering an HTTP redirect had to be defined per HTTP request by setting an attribute. Now there is also a new redirect policy that can be set globally in QNAM. If redirect behavior is to be specified in multiple ways, the first priority is defined per request with a policy, the second is per request with an attribute and finally the global QNAM policy takes control. Another major improvement is the HTTP Strict Transport Security (HSTS) support. HSTS is a web security policy, described in RFC6797, that allows a web server to declare that user agents should only interact with it using secure HTTPS connections.

We have some platform specific improvements as well as support for new platforms and compilers coming with Qt 5.9. Especially macOS is receiving many improvements, as we are updating the macOS platform plugin in order to support modern and future features of the operating system, especially on the graphics side. For Windows users, Qt 5.9 targets to bring support for the new VS2017 compiler. We may also be offering pre-built binaries for VS2017 with Qt 5.9 (depending on when VS2017 is released). With Qt 5.9 we are re-introducing support for INTEGRITY allowing creation of safety critical systems with Qt on top of the INTEGRITY RTOS.

These are examples of some of the new things coming with Qt 5.9, for full list of features please check http://wiki.qt.io/New_Features_in_Qt_5.9.

Directions for Qt 5.10 and Beyond

After the branching of Qt 5.9 the dev branch now contains what will become Qt 5.10. It is planned to be released in November 2017 and its development has already started. We are currently finalizing the development priorities and here are some items we have been considering to do for Qt 5.10.

Qt is very widely used with over one million developers and a vibrant ecosystem. Sometimes a user just starting with Qt may find it a bit challenging to get going. One reason for this challenge is the fact that Qt is so versatile – we often offer multiple ways of developing applications. Sometimes it may also happen that parts of our documentation and examples are slightly outdated or do not clearly highlight what is the best approach for the user. While the work with documentation and examples is a constant effort, with Qt 5.10 we are planning to have a further push to improve the experience of getting started with development of Qt application and devices.

Running Qt applications in a browser via Native Client (NaCl) has been possible since 2009 and since Qt 5.8 VNC can be used for remote control of Qt applications. However these options are often not as convenient as desired. With Qt 5.10 we are planning to support streaming of Qt Quick application UIs over a network to a browser using WebGL. This streaming of OpenGL commands will allow using a common browser as a remote display of a Qt application running e.g. in a nearby embedded system or far across a network. Input from touch/mouse as well as keyboard is transmitted back to the Qt application. WebGL streaming will be implemented as a platform plugin in Qt 5.10. The streaming plugin converts all painting commands to WebGL commands and transmits the streams to clients. In turn those clients transmit user input back. Clients can be Qt applications or any web browser capable of showing WebGL 1.0.

On the graphics domain we are working with some nice additions targeting Qt 5.10. The first one being support for arbitrary path rendering (i.e. shapes) in Qt Quick. This allows declaratively specifying complex shapes built from lines, curves and arcs directly in QML and rendering them in an accelerated manner. Continuing on the approach started with the scenegraph modularization in Qt 5.8, the solution is expected to have multiple backends internally. For instance, NVIDIA-based systems will be able to utilize the GL_NV_path_rendering OpenGL extension transparently to the applications. The second new item is to provide basic Vulkan enablers in Qt. These allow creating Vulkan-capable windows and integrating code performing rendering with Vulkan into Qt C++ applications on multiple platforms, while abstracting and hiding the platform and windowing system specific bits. The third item we are researching is to use modern OpenGL features in Qt. Especially those offered by OpenGL ES 3.2 are quite interesting to improve the Qt Quick scenegraph performance and to potentially introduce new features like e.g. built-in support for compressed textures.

In the 3D area, we recently received a major contribution from NVIDIA, who contributed their complete 3D UI development tooling to Qt. During the coming year we will develop the tooling and its Qt integration further to enable smooth creation of 3D UIs for Qt applications. We will improve the existing integration into Qt and introduce more Qt functionality within the tooling itself. In the long term, we are also aiming to port the tooling to fully leverage Qt to support Mac and Linux hosts for development (initially the tool is for Windows only). For deployment the tool will support all desktop, embedded and mobile platforms generally supported by Qt. To check out what is already possible with the tool, please read the the recent announcement blog post for Qt 3D Studio.

Patch Releases and Long-Term Support

In addition to feature releases we make patch releases providing improvements to functionality introduced in those new feature releases. The primary purpose of a patch release is to provide a collection of bug fixes to issues found in the .0 feature release. Typically, the first patch release contains many fixes which were already completed at the time of the .0 release, but were not considered critical. The bug fixes done after the .0 release will end up in the next patch level release, as well as merged up to the next feature release.

Unfortunately, we have not been as efficient in providing the patch releases as we would like to. For Qt 5.7 we only created one patch release in December, almost 6 months after the Qt 5.7.0 release. We are currently renewing the CI system infrastructure, which will increase the capacity of the Qt CI system and allows us to make more patch releases from Qt 5.9 onwards. Unless there are significant security or other issues found, we are not planning to provide any patch releases for Qt 5.8 to make sure that we release Qt 5.9.0 with the planned schedule. Qt Support will assist customers to overcome possible issues found in Qt 5.8.0 release.

For Qt 5.6 LTS we have already provided two patch level releases adding quite a lot of improvements. Going forward we will make less changes to the Qt 5.6 LTS version. Since Q4/2016 we have already reduced the number of fixes going into the 5.6 branch. While each fix as such is beneficial, they are also possible risks for behavior changes and regressions, which we want to avoid in LTS releases. Next patch release, Qt 5.6.3 LTS, is planned to contain only fixes for critical bugs and security issues. The planned timing of Qt 5.6.3 is after Qt 5.9 has been released.

We are considering possibilities to extend support of Qt 5.9. The decision has not yet been made whether it should be a generic LTS or something that is provided only for selected platforms (e.g. embedded only). In any case we intend to create more patch releases for it than we have been able to do for Qt 5.7 and 5.8. The ongoing improvements and increasing the capacity of our CI system will help achieve this.

Get involved

During the coming months we will be hosting several webinars about key features in Qt 5.8. There will also be many blog posts about the new innovations in Qt targeting Qt 5.9 and Qt 5.10. If you want to learn more about Qt, please contact our sales teams or join the discussion in the Qt mailing lists and developer forums. We are always delighted to see new contributors in the Qt Project as well as feedback to the pre-releases of Qt via bugreports.

If you are interested in working with us to shape the future of Qt, we have many open positions at The Qt Company.

The post Qt Roadmap for 2017 appeared first on Qt Blog.

Making Movies with QML

by Andy Nichols (nezticle) (Qt Blog)

One of the interesting things about working with Qt is seeing all the unexpected ways our users use the APIs we create.  Last year I got a bug report requesting an API to set a custom frame rate for QML animations when using QQuickRenderControl.  The reason was that the user was using QQuickRenderControl as an engine to render video output from Qt Quick, and if your target was say 24 frames per second, the animations were not smooth because of how the default animation driver behaves.  So inspired by this use case I decided to take a stab at creating such an example myself.

screen-shot-2017-02-21-at-12-46-27

This may not be the most professional looking User Interface, but what it does is still pretty neat.  The objective is to feed it an animated QML scene and it should output an image file for each frame of the animation.  These images can then be converted into a video or animated image using an external tool.  The challenge is that Qt Quick is a UI tool, not a movie generator.

The naive approach to this would be to create a QQuickWindow, set the window size to the output target size, and then grab the frame by calling QQuickWindow::grabWindow() each time the frameSwapped() signal is emitted.  There are a couple of issues with this approach though.  First is that the video would need to render in realtime.  If you wanted to render an animation that was 5 minutes long, it would take 5 minutes because it would just be like recording your application for 5 minutes.  The second issue is that under the best case scenario you would be rendering video at the refresh rate of your monitor. This would even require a reasonably powerful machine, because the QQuickWindow::grabWindow() call involves a glReadPixels call which is quite expensive.  It is also problematic if you need to render at a different frame rate than your monitor refresh (which is what the user that inspired me was complaining about).  So here is how I addressed both of these issues.

QQuickRenderControl

QQuickRenderControl is a magical class that lets you do all kinds of crazy things with Qt Quick content.  For our purposes we will use it to render Qt Quick content to an offscreen surface as fast as we can.  Rather than creating an on-screen QQuickWindow, we can create a dummy QQuickWindow and via render control we can render content to an QOpenGLFramebufferObject instead.

    // Setup Format
    QSurfaceFormat format;
    format.setDepthBufferSize(16);
    format.setStencilBufferSize(8);

    // Setup OpenGL Context
    m_context = new QOpenGLContext;
    m_context->setFormat(format);
    m_context->create();

    // Setup dummy Surface (to create FBO with)
    m_offscreenSurface = new QOffscreenSurface;
    m_offscreenSurface->setFormat(m_context->format());
    m_offscreenSurface->create();

    // Setup Render Control and dummy window 
    m_renderControl = new QQuickRenderControl(this);
    m_quickWindow = new QQuickWindow(m_renderControl);

    // Setup QML Engine
    m_qmlEngine = new QQmlEngine;
    if (!m_qmlEngine->incubationController())
        m_qmlEngine->setIncubationController(m_quickWindow->incubationController());

    // Finish it all off
    m_context->makeCurrent(m_offscreenSurface);
    m_renderControl->initialize(m_context);

The above gets QQuickRenderControl setup, then when the size is know and you can actually create the QOpenGLFramebuffer object and tell the dummy QQuickWindow thats where it will be rendering.

void MovieRenderer::createFbo()
{
    m_fbo = new QOpenGLFramebufferObject(m_size * m_dpr, QOpenGLFramebufferObject::CombinedDepthStencil);
    m_quickWindow->setRenderTarget(m_fbo);
}

And once that is done it’s just a matter of loading up the QML content and rendering it.  Unlike with QQuickWindow, QQuickRenderControl allows you to control when the steps of the rendering process occurs.  In our case we want to render as fast as possible so this is what our rendering setup looks like:

void MovieRenderer::renderNext()
{

    // Polish, synchronize and render the next frame (into our fbo).
    m_renderControl->polishItems();
    m_renderControl->sync();
    m_renderControl->render();
    m_context->functions()->glFlush();

    m_currentFrame++;
 
    // Grab the contents of the FBO here ...

    if (m_currentFrame < m_frames) { 
        // Schedule the next update 
        QEvent *updateRequest = new QEvent(QEvent::UpdateRequest); 
        QCoreApplication::postEvent(this, updateRequest);
    } else { 
        //Finished cleanup();
    } 
} 
bool MovieRenderer::event(QEvent *event) { 
    if (event->type() == QEvent::UpdateRequest) {
        renderNext();
        return true;
    }
    return QObject::event(event);
}

The above sets up an event driven loop that will render as fast as possible while still handling events between frames, which is needed for progressing animations with Qt Quick.

Custom QAnimationDriver

The second issue we need to address is that the animation behavior is wrong.  To remedy this we need a custom QAnimationDriver that enables us to advance animations at our own frame rate.  The default behavior is to try and advance the animation’s in steps as close as possible to the refresh rate of the monitor your application is running on.  Since we never present the content we render to the screen that behavior doesn’t make sense for us.  Instead we can install our own QAnimationDriver which can be manually advanced each frame we generate based on a pre-determined frame rate.  Here is the whole implementation of my custom Animation driver:

class AnimationDriver : public QAnimationDriver
{
public:
    AnimationDriver(int msPerStep)
        : m_step(msPerStep)
        , m_elapsed(0)
    {}

    void advance() override
    {
        m_elapsed += m_step;
        advanceAnimation();
    }
    qint64 elapsed() const override
    {
        return m_elapsed;
    }
private:
    int m_step;
    qint64 m_elapsed;
};

Now to use this you just need to install the new QAnimationDriver.  When you call QAnimationDriver::install() it will replace the current one, so Qt Quick will then behave like we need it to.  When we start the movie renderer we also install the custom AnimationDriver:

    m_frames = m_duration / 1000 * m_fps;
    m_animationDriver = new AnimationDriver(1000 / m_fps);
    m_animationDriver->install();

    // Start the renderer
    renderNext();

And finally since we control the render loop, we need to manually advance the animation driver.  So before the end of the renderNext() method make sure to call:

m_animationDriver->advance();

And that is it.  Now we can render as fast as possible, and our animation engine will step perfectly for the frame rate we are generate frames for.  It is important to remember that you must process events after calling advance() on your animations though, because these are handled through the Qt Event and Signal and Slots system.  If you don’t do this, then you will generate the same frame many times.

Results

Once you run the MovieRenderer you end up with a folder full of images representing each frame.  To prepare video files from the generated output I used ffmpeg:

ffmpeg -r 24 -f image2 -s 1280x720 -i output_%d.jpg -vcodec libx264 -crf 25 -pix_fmt yuv420p hello_world_24.mp4

In the above command it will generate a 720p video at 24 fps from a series of files called output_*.jpg.  It would also be possible to create an example that either called this tool for you via QProcess, or even included an encoder library to generate the video directly.  I went for the simplest approach using only what Qt had built-in for this example.  Here are a few example movies I generated:

This first video is rendered at 60 FPS and the second is at 24 FPS.  Notice how they animate at the same speed but one is smoother than the other.  This is the intended behavior in action.

Well thats all I have to show, the rest is up to you.  I’ve published the code for the QML Movie Renderer here so go check it out now!  I hope this example inspires you as well to make other cool projects, and I look forward to seeing what new unexpected ways you’ll be using Qt in the future.

The post Making Movies with QML appeared first on Qt Blog.

QStringView Diaries: Advances in QStringLiteral

This is the first in a series of blog posts on QStringView, the std::u16string_view equivalent for Qt. You can read about QStringView in my original post to the Qt development mailing-list, follow its status by tracking the “qstringview” topic on Gerrit and learn about string views in general in Marshall Clow’s CppCon 2015 talk, aptly […]

The post QStringView Diaries: Advances in QStringLiteral appeared first on KDAB.

Introducing Qt 3D Studio

Over the last years, a lot of work has happened to make it easier to use 3D technologies in and with Qt.

I’m now extremely happy to let you know that we can now do a huge step forward towards providing competitive, designer friendly tooling as part of our offering in the future.

NVIDIA did one of the largest contributions ever to Qt. They chose to contribute the whole NVIDIA DRIVE™ Design Studio, a designer friendly 3D UI authoring system, to Qt. NVIDIA DRIVE Design Studio is a well proven product that has been used for production systems in many industries.

The contribution consists of several hundred thousand lines of source code. It consists of a runtime component, designer friendly tooling and a Qt integration. This will allow us to bring state-of-the-art 3D tooling to the whole Qt ecosystem. As the title of this blog post suggests, we do even have a name for it already: Qt 3D Studio.

Have a look at the video below to see it in action:

Our goal is to integrate this closely, so that designers can easily create 3D user interfaces that are easily integrated with the rest of the application written in Qt. The UIs can then also easily be extended using Qt Quick or Qt 3D.

Qt 3D Studio is not meant to replace any of our existing UI technologies (Qt Widgets, Qt Quick or Qt 3D), but will nicely complement them.

There is still a lot of work left to closely integrate the code base and especially the runtime with the rest of Qt. As an example, the UI for the tool is currently using MFC in some parts, so it only works on Microsoft Windows. We are also working on ensuring that the tool and runtime will be fully cross-platform and work on all operating systems and GPUs supported by the rest of Qt.

 

Qt 3D Studio will be available under both open-source and commercial licensing terms, and will be developed in the open, just as the rest of Qt. But as we have only just received the contribution from NVIDIA, it’ll take use a bit to sort through the source code and mold it into a form that we can publish. So please bear with us for a little while, we’ll keep you posted on all progress.

We’re all extremely excited about this contribution to Qt, and I’d like to close this blog post with a big ‘Thank you!’ to NVIDIA.

The post Introducing Qt 3D Studio appeared first on Qt Blog.

Boot to Qt on embedded HW using Android 7.0 and Qt 5.8

One can have real pain trying to create a demo setup or proof-of-concept for an embedded device. To ease the pain Qt for Device Creation has a list of supported devices where you can flash a “Boot to Qt” image and get your software running on the target HW literally within minutes.

Background

Back in 2014 we introduced a way to make an Android device boot to Qt without the need of a custom OS build. Android has been ported to several devices and the Android injection method made it possible to get all the benefits of native Qt applications on an embedded device with the adaptation already provided by Android.

The Android injection was introduced using Qt versions 5.3.1. whereas the supported Android versions were 4.2 and 4.4. It is not in our best interest that anyone would be forced to use older version of Qt, nor does it help if the Android version we support does not support the hardware that the developers are planning to use. I have good news as the situation has now changed.

Late last year we realized that there still is demand for Android injection on embedded devices so we checked what it takes to bring the support up to date. The target was to use Qt 5.8 to build Boot to Qt demo application and run it on a device that runs Android 7.0. The device of choice was Nexus 6 smartphone which was one of the supported devices for Android Open Source Project version 7.0.0.

The process

We first took the Android 7.0 toolchain and updated the Qt 5.4 Boot to Qt Android injection source code to match the updated APIs of Android 7.0. Once we could build Qt 5.4 with the toolchain, it was time to patch the changes all the way to Qt 5.8.
Since Qt version 5.4 there has been improved modularity in Qt and it became apparent during the process, e.g. the old Surfaceflinger integration was replaced with a platform plugin.

The results can be seen in the videos below.

The Boot to Qt Android injection is an excellent way to speed up the development and get your software to run on target hardware as early as possible. If you want to know more about the Boot to Qt and Android injection, don’t hesitate to contact us.

The post Boot to Qt on embedded HW using Android 7.0 and Qt 5.8 appeared first on Qt Blog.

Cutelyst 1.4.0 released, C100K ready.

Yes, it's not a typo.

Thanks to the last batch of improvements and with the great help of jemalloc, cutelyst-wsgi can do 100k request per second using a single thread/process on my i5 CPU. Without the use of jemalloc the rate was around 85k req/s.

This together with the EPoll event loop can really scale your web application, initially I thought that the option to replace the default glib (on Unix) event loop of Qt had no gain, but after increasing the connection number it handle them a lot better. With 256 connections the request per second using glib event loop get's to 65k req/s while the EPoll one stays at 90k req/s a lot closer to the number when only 32 connections is tested.

Beside these lovely numbers Matthias Fehring added a new Session backend memcached and a change to finally get translations to work on Grantlee templates. The cutelyst-wsgi got --socket-timeout, --lazy, many fixes, removal of usage of deprecated Qt API, and Unix signal handling seems to be working properly now.

Get it! https://github.com/cutelyst/cutelyst/archive/r1.4.0.tar.gz

Hang on FreeNode #cutelyst IRC channel or Google groups: https://groups.google.com/forum/#!forum/cutelyst

Have fun!

Qt 5.5.1-2 for Wind River® VxWorks® Real-Time Operating System Released

The Qt 5.5.1-2 release for VxWorks Real-Time Operating System (RTOS) release supports the new VxWorks 7 release SR 0480 (September 2016) on ARM-v7 with updates in the Qt Base, Qt Declarative and Qt Quick Controls modules. For full list of changes, please see the change log.

To learn more about Qt 5.5 for VxWorks, please check out:

Existing licenses of Qt for VxWorks can download the new release from their Qt Account web portal and run it on top of the SR 0480 (September 2016) release of VxWorks 7 RTOS. If you wish to conduct a technical evaluation, please contact us to request an evaluation.

If you are planning to visit Embedded World in Nürnberg 14th – 16th March 2017, please come to see Qt at Hall 4, Stand 4-258 and Wind River at Hall 4, Stand 158.

Qt will also be in Wind River’s booth at HIMSS 2017 Booth#7785-21 showcasing a Qt for Medical IoT Heart rate monitor using VxWorks7 and Helix Cloud on i.MX6 built with Qt. Learn more.

VxWorks real-time operating system has been building embedded devices and systems for more than 30 years and powers more than 2 billion devices. To learn more about VxWorks, please visit the VxWorks webpage or contact Wind River.

The post Qt 5.5.1-2 for Wind River® VxWorks® Real-Time Operating System Released appeared first on Qt Blog.

QtWebKit: I'm back!

Hello world!

 

Five years have passed since the last entry in this blog, and almost 3 years since infamous "Changes in QtWebKit development" thread at webkit.org. Fortunately, we've made quite different kind of change in QtWebKit development lately, and it is much more exciting.

QtWebKit is back again!


If you were following QtWebKit development after 2013, you know that actually development have never stopped: each release was getting a bunch of bugfixes and even brand new features. However, WebKit engine itself has not been updated since Qt 5.2 release. That's why it didn't support recent changes in Web standards that happened after 2013, including: new JavaScript language standard ES2015 (also known as ES6), as well as improvements in DOM API and CSS.

However, things have changed in 2016, and now we have revived QtWebKit! Core engine code was updated to it's actual state, and as a result we (and you!) can use all improvements made by WebKit community during these 3 years without any changes in code of existing Qt applications!



You may be wondering, why anyone would like to use QtWebKit in 2016, when shiny new QtWebEngine is available? There is a number of reasons:
  • When used in Qt application, QtWebKit has smaller footprint because it shares a lot of code with Qt. For example, it uses the same code paths for drawing and networking that your regular Qt code uses. This is especially important for embedded systems, where both storage space and memory are scarce resources. It's possible to go further and cut away features which are not crucial for your application, using flexible configuration system of WebKit.
  • On Linux QtWebKit uses GStreamer as a default media player backend. This means that application users will be able to use patent encumbered codecs (if this is legal in their areas) without getting you (as application developer or distributor) into legal troubles.
  • Lots of existing open source applications depend on QtWebKit, but without security updates their users are left open to vulnerabilities. The are only two ways to work around this problem: port applications away from QtWebKit (which is often a hard task because QtWebKit allows much deeper integration with application code than alternative solutions), or update QtWebKit itself, which makes these large porting work unnecessary.
  • QtWebKit is more portable than Chromium: it can run on any CPU architecture supported by Qt and on virtually any Unixish OS (as well as Windows and Mac). The only requirement is a C++11 compiler.
  • Non-interactive user agents like PhantomJS or wkhtmltopdf don't gain any benefits from multi-process architecture, so using single-process WebKit 1 API allows them to have less resource footprint and simpler flow of execution.

    Q: I've heard that WebKit engine is not relevant anymore, since the crowd is working on Blink these days!


    A: This is not true. Despite of the Google departure, WebKit remains on of the leading browser engines, and is progressing at a fast pace. If you don't believe, read on! Also you may want to read release announcements of Safari Technology Preview and WebKitGTK, which higlight other WebKit features under development.

    Now let's see what can we do with QtWebkit in 2016!

    JavaScript engine improvements and ES2015 status

     

    Most of features are supported now (QtWebKit 5.6 has 10% rating). Note that WebKit is the first web engine providing proper tail calls, which means you can enjoy functional programming without unnecessary stack growth in tail recursion!

    WebKit gained new tier of JavaScript JIT compilation, called FTL. First implementation was based on LLVM compiler infrastructure, but now we are shipping B3 compiler which is more lightweight, does not pull in additional dependencies, and also compiles faster. FTL usually gets activated for computationally-intensive JS code, and is especially useful for running native code compiled to ASM.js.

    Code produced by JavaScript JIT now uses normal C stack, reducing overall memory usage and fragmentation.

    JIT compiler now uses background threads, so compilation does not block execution of other code.


    New (and old) CSS properties


    Web standards evolve rapidly, and more and more CSS properties find their way into specification. Most of them have already been available for a long time, but used -webkit vendor prefix as they were non-standard extensions at a time of their introduction, and now they (finally!) have formal description which all vendor are obliged to follow (though sometimes standardization process changes behavior of old properties). Standardized properties are available without vendor prefixes, and web page authors start actively using these new spelling.

    Unfortunately, sometimes they break compatiblity with old browsers, which implement prefixed properties, with disastrous consequences. Here are screenshots of site that uses unprefixed flexbox properties, defined in CSS3:

      QtWebKit 5.6


      QtWebKit TP3

      CSS Selector JIT


      Besides JavaScriptCore, WebKit now features yet another JIT compiler. Its aim is to speed up application of CSS style sheet to elements of page DOM, so called style resolution. Average performance gain is about 2x, however for complex selector and/or pages with lots of DOM nodes gain may be substantially larger.

      Selector JIT also makes querySelector() and querySelectorAll() faster, but speed up factor may differ.

      -webkit-initial-letter


      This is new CSS property, allowing page author to create "drop cap" effect without much hassle. In order to make this effect work correctly with calligraphic fonts, Qt 5.8 (not yet released) is required.

      Other improvements


      • Responsive images support (<picture> element, srcset and sizes attributes)
      • ellipse()method in Canvas API
      • CSS selectors ::read-writeand ::read-only
      • HTML <template>element 
      • APNG images

      We also support following web features with experimental status and only for GStreamer media player backend:
      • Media Source Extensions
      • WebAudio


        The path ahead


        Unfortunately, porting Qt-specific code to the new WebKit is not always easy, and we had to disable certain features until all code behind them is ported properly. So far, following prominent features are not yet working:
        • QML API
        • WebGL and CSS 3D transforms
        • Accelerated compositing
        • Private browsing
        However, don't be discouraged! Work is in progress and we hope to get these feature available soon. But we are short on manpower so we cannot work on many things in parallel. If you want to get your favorite feature ready sooner rather than later, please join our project. We have a lot of work to do, most items don't require any prior knowledge of WebKit, and some even don't require you to know C++ (yes, there is work for those of you who know only HTML + CSS + basic JavaScript, or only Python). Another way to help us is to report bugs you have found, or help to track down known issues.

        You can follow development of QtWebKit at GitHub repository; however if you want to obtain get bleeding edge sources, use another repository - the latter one is much smaller than original, but still contains all files required to build QtWebKit. See our wiki for build instruction and additional information about the project.

        P.S.


        Today is 10 years since the first chunk of QtWebKit code have been merged into WebKit repository. See https://bugs.webkit.org/show_bug.cgi?id=10466 for more details.

        Update


        Technology Preview 3 is now available: release notes, tarball. Binaries for Windows and macOS will be uploaded a bit later.

        Update 2


        Technology Preview 5 is available now. It includes binaries for Windows (MSVC, MinGW), macOS, and Linux, that are fully compatible with official Qt 5.8.0 SDK.

        SpeedCrunch 0.12 Released

        Almost 3 years and 700 000 downloads later, here's the core new features of this release:
        If you're curious, check out the complete list of enhancements and bug fixes. Or go straight to the downloads page. For better productivity, learn about all the user interface quirks at your disposal.

        MacOS users: please note that a download is not yet available for you. If you can help us with that, please get in touch. (download is now available, thanks to Samuel Gaist).

        Don't forget to report issues or request new features in our tracker. See more ways to contribute in the Help menu on the new website. Please help us release 1.0 as quickly as possible. Have a look at what's planned already.

        Massive thank you to TeyutPol WelterFelix KrullHadrien Theveneaul.inc, all the translators at Transifex, and the folks over at Portable Apps (for representing a nice chunk of our user base).

        Cheers

        Missed the Qt World Summit 2016 sessions?

        The Qt World Summit 2016 sessions recordings are now available on-demand! Whether you had the chance to see us at #QtWS16 live last year or missed us, you can watch experts covering everything from the Future of technology, HMI strategy planning and project management to deep dives into user experience design for software engineers and much more.

        There was a lot happening on-stage by a myriad of speakers including Qt company experts, industry leaders, and our more than capable partners–and you can relive those moments.

        Recommended categories:

        • Keynotes – watch how we kick-started #QtWS16!
        • Deep tech and UI/UX – get the tips & tricks from the Qt experts
        • Built with Qt – check out the buzz around Qt in the industry

        So pull up a chair, grab a beverage and enjoy the show!

        And in case you missed it, see what #QtWS16 attendees from Ubuntu, Tableau, and LG had taken away about Qt:

        To stay tuned for Qt World Summit 2017 updates, subscribe for the newsletter at http://www.qtworldsummit.com.

        The post Missed the Qt World Summit 2016 sessions? appeared first on Qt Blog.

        Glowing Qt Charts

        Have you ever had the need to visualize data graphically and add some ‘wow’-effect to it? I’m currently helping out with the development of a demo application, where we have some charts to visualize data received from sensors. Naturally, the designer wants the charts to be visually appealing.

        At the beginning we had basic graphs to show the data, one of them being temperature. We used LineSeries QML type from Qt Charts with dynamic for this.

        Temperature represented as LineSeries.

        Now to make the graph more polished we decided to hide the labels and the grids drawn to the chart and make the background transparent. This way we had only the series drawn to the area reserved for the graph. To achieve this we modified our ChartView with two axis and a series to the following:

        ChartView {
            id: chartView
            backgroundColor: "transparent"
            legend.visible: false
        
            ValueAxis {
                id: valueAxisX
                min: 0
                max: maxNumOfTempReadings + 1
                visible: false
            }
        
            ValueAxis {
                id: valueAxisY
                min: minimum
                max: maximum
                visible: false
            }
        
            LineSeries {
                id: avgTempSeries
                axisX: valueAxisX
                axisY: valueAxisY
                color: chartColor
            }
        }
        

        But having just the series was no fun. With the main background of the application and the temperature values we had a chart that looked like in the following picture.

        Temperature chart without effects.

        As the design specification had some glow on elements in the UI, we decided to give a try to some graphical effects QML has to offer, more precisely the Glow effect. We added the Glow element to the same level with the ChartView (Glow and ChartView elements are siblings).

        Glow {
            anchors.fill: chartView
            radius: 18
            samples: 37
            color: "#15bdff"
            source: chartView
        }
        

        With the above code it was very easy to add some glow to the chart series. The same chart as shown in the beginning with the mentioned changes and some additional elements ended up looking like in the following picture.

        Temperature graph with a glowing series.

        Want to spice up your charts? Go and give it a try, it’s really easy.

        The post Glowing Qt Charts appeared first on Qt Blog.

        Native look and feel

        by Richard Moe Gustavsen (Qt Blog)

        We know that many Qt users want controls styled with a native look-and-feel. But offering that on platforms with no public styling API, is hard. A classic approach is to take snapshots of the native controls, tweak them, and use them as foreground or background in our own controls. Which is somewhat OK for static appearances. But when animations and transitions are involved, static pixmaps will only take you half the way. And since an OS can change style from one update to the next, taking snapshots runtime is risky. Using pre-grabbed snapshots is also something we don’t do because of legal considerations.

        Since December last year, the controls team has been researching a bit small scale on a new project to offer controls with true native look-and-feel. The aim is to do the alternative to the above standing, and explore how feasible it would be to wrap actual native controls into a cross platform Qt API. Such ideas is nothing new of course, and have been discussed many times, at least internally. One of the problems is that different platforms can vary quite much API-wise, especially for more complex controls like tab-, and split views, with some having a rich API, while others are more limited. And unifying that into a common useable Qt API is a challenge.

        Currently we have prototyped a set of controls, together with a plugin-based framework and a few backends for testing (uikit, appkit, android). The API is small and strict so that it can be realized on all supported (and future) platforms. As such, the controls become rather black box, since we cannot make assumptions on how they are implemented by the backends. Still, there will be times when you need to detail how your application should work on a specific platform. For that reason we plan to open up, and factor out, the various backends into separate libraries that can be accessed directly. Those libraries will wrap parts of the native APIs more closely, and offer building blocks specific to the platform, or controls with a broader set of functions and properties. They will be more open than the common controls, giving access to the native controls they wrap, to let you dig into to native development whenever you need to fill gaps that falls outside our own scope. In the end, it should be easy and straightforward to mix cross-platform controls, platform-specific controls, and native code in your application.

        I’ve mentioned “APIs” a couple of times. This of course includes QML. But we also plan to offer direct access to the underlying C++ libraries, making it easy to extend the API, and write applications using C++ only. That way you can choose whether you want to use QML, C++, or a combination.

        Here is a snippet showing how things look so far. The app mixes a couple of cross-platform controls (common controls) together with a control directly from the AppKit backend.

        import QtQml 2.0
        import Qt.CommonControls 1.0 as Common
        import Qt.AppKitControls 1.0 as AppKit
        
        Window {
            id: window
            visible: true
        
            Common.Button {
                id: button
                x: 20
                y: 20
                text: "Click me"
                onClicked: text ="You clicked me!"
            }
        
            Common.TextField {
                id: textField
                placeholderText: "TextField"
                x: 20
                y: button.bottom + 8
            }
        
            AppKit.SearchField {
                placeholderText: "Search"
                x: 20
                y: textField.bottom + 8
            }
        }
        

        The next snippet shows the same app, but this time in C++

        int main(int argc, char *argv[])
        {
            QGuiApplication app(argc, argv);
            QCommonWindow window;
        
            QCommonButton commonButton(QStringLiteral("Click me"), &window);
            commonButton.move(20, 20);
            QObject::connect(&commonButton, &QCommonButton::clicked, [&commonButton](){
                commonButton.setText(QStringLiteral("Clicked!"));
            });
        
            QCommonTextField textField(&window);
            textField.setPlaceholderText(QStringLiteral("TextField"));
            textField.move(20, commonButton.bottom() + 8);
        
        #if defined(Q_OS_MACOS)
            QAppKitSearchField searchField;
            searchField.setParent(&window);
            searchField.move(20, textField.bottom() + 8);
            NSSearchField *nsSearchField = searchField.nsSearchFieldHandle();
            nsSearchField.placeholderString = @"Search...";
        #endif
        
            window.showFullScreen();
            return app.exec();
        }
        

        As mentioned, we plan to keep the API rather strict. The common controls will only contain the basics, with few, or no possibilities for tweaking the style, catching internal events, or overriding default behaviour. You basically get native controls with native look, feel and behaviour. If you, on the other hand, need custom styling, or your own custom controls, Qt offer solutions like QtQuickControls2, or Widgets, for that already. Our current thinking is that this module will be something for Qt6.

        The post Native look and feel appeared first on Qt Blog.

        Release 2.10.0: New App Showcase, Multiplayer & Multi-Language Improvements, Qt 5.8

        V-Play 2.10.0 is here and it includes all the new features of Qt 5.8, as well as Qt Creator 4.2.

        It adds a new Showcase App which combines all V-Play app demos in one application. It includes some of the most common app components used today and you can access it’s full source code from your V-Play installation. You can read more about it here!

        apps-demo-showcase
        You can check out these features by downloading the Showcase app for free. You can get it for Android from the Google Play Store or for iOS from the App Store.

        The update also includes a number of new V-Play Multiplayer features to improve matchmaking. Check out the details here and find out how you can now add and remove players during live games.

        As well as that, V-Play 2.10.0 improves support for language localization within mobile apps and games. You can now develop your apps and games using your default language and V-Play will automatically find the best translations for your text!

        V-Play developers can find details on how to successfully update to Qt 5.8 here.

        New V-Play developers can sign-up now and get the tool for free!

        Update V-Play Now!

        Qt 5.8 and Qt Creator 4.2 Support

        V-Play 2.10 lets you use features from the newly released Qt 5.8 and Qt Creator 4.2. This update includes a wide-ranging selection of new features, including Qt Quick Controls 2.1. Check out this video to learn more about the update:

        Along with these new Qt features, V-Play 2.10.0 gives you advanced language support and new in-app purchase features.

        Internationalization Support

        V-Play apps and games now make it easier to support multiple languages. Create your app using default texts and easily support different countries and languages by enabling translations.

        The correct translation is automatically chosen based on the detected system language of the device. To manually switch the language at runtime, use the new GameWindow::settings.language property. This feature can be added to your app or game in minutes with this block of code:

        
        
        GameWindow {
           Scene {
        
             Column {
               // create a localizable text with qsTr() and
               // make it dynamically change by binding to translation.language
               Text {
                 anchors.horizontalCenter: parent.horizontalCenter
                 text: qsTr("Hello World") + translation.language
               }
        
               // toggle language between german and english on button press
               ButtonVPlay {
                 readonly property bool isEnglish: settings.language === "en_EN"
        
                 text: "Switch to " + (isEnglish ? "German" : "English")
                 onClicked: settings.language = isEnglish ? "de_DE" : "en_EN"
               }
             }
           }
         }
        
        

        You can read How to Make a Multi Language App or Game with V-Play for more information!

        SyncedStore

        You can now use the SyncedStore component together with the Soomla Plugin to synchronize your in-app purchases across devices.

        This new feature allows users to purchase goods in your game or app as before, but additionally uses the V-Play Game Network WebStorage to synchronize the balance of your virtual goods and currencies between the user’s devices.

        How to Update to Qt 5.8

        Make your switch to the latest versions of V-Play and Qt as smooth as possible with these guidelines:

        • After updating, open the MaintenanceTool in your V-Play SDK installation folder and remove Qt 5.7 from your installed components. Since V-Play is not compatible with Qt 5.7 anymore, it is best to remove these kits.
        • Qt Creator should automatically detect the kits for Qt 5.8, which you can use to build your V-Play projects.
        • To enable one of the new Qt 5.8 kits, click “Projects” on the left side of Qt Creator and enable your desired kit in the tree below “Build and Run”

        qt creator

        • Qt 5.8 for Android requires the latest Android NDK. You can download the NDK here.

        Showcase Component App Update

        The updated Component Showcase Demo App combines the most important V-Play Apps features in a single app with native user experience (UX) and fluid UI animations.

        iOS                                                                                        Android

        apps-demo-showcase-ios-1  apps-demo-showcase-android-1

        You can use the showcase app to see how V-Play Apps handles:

        • Theming and native platform styles
        • Native dialogs, camera/image picker and share features
        • Embedded maps and GPS positioning
        • Embedded video, audio and WebView
        • Shader effects and fluid animations
        • Native styled controls and Qt Quick Controls
        • Local storage, app navigation, lists and sections
        apps-demo-showcase

        Download the Showcase Component App

        The V-Play Showcase Component app is one of the easiest ways for you to see the power of V-Play. Best of all, you can access the full source code of the app from your V-Play installation. You can use this source code in any way you like to build mobile apps or games.

        iOS

        apps-demo-showcase-ios-2 apps-demo-showcase-ios-3 apps-demo-showcase-ios-4 apps-demo-showcase-ios-5

        Android

        apps-demo-showcase-android-2 apps-demo-showcase-android-3 apps-demo-showcase-android-4 apps-demo-showcase-android-5

        Sign-up for V-Play now and check out the source code for free!

        You can launch the Showcase Component App from the V-Play Sample Launcher, Qt Creator or from your installation directory.

        You can also download it free for iOS from the App Store or for Android from the Google Play Store.

        google_play_badge-1 itunes_download_link

        Improvements

        V-Play 2.10.0 includes more improvements to V-Play Game Engine, V-Play Apps and V-Play Plugins than any other recent update.

        V-Play Apps

        V-Play 2.10.0 includes lots of new features and improvements for mobile app development.

        Native Sliders

        You can now build even better UIs with our native looking sliders for iOS and Android. Use the AppSlider or AppRangeSlider controls to select values and ranges with native appearance for iOS and Android.

        appslider-control-iosapprangeslider-control-ios
        appslider-control-androidapprangeslider-control-android

        AppFlickable Component

        The update includes scrolling and display improvements to the AppFlickable component.

        It now uses a default maximumFlickVelocity of dp(3000) which matches the AppListView flick velocity. It also supports scrolling to the top when the statusbar is clicked on iOS.

        Navigation Styling

        V-Play 2.10.0 includes a number of new styling options for the NavigationBar component. You can now show or hide the NavigationBar drop shadow with the new NavigationStack::navigationBarShadow property.

        You can also show or hide a drop shadow below the NavigationBar on Android with the NavigationStack::navigationBarShadow property. The shadow height is customizable with the Theme.navigationBar.shadowHeight setting.

        As well as that, the PageControl component now allows you to jump to a specific page by directly clicking the indicator.

        More Changes

        For a full list of improvements to V-Play Apps in this update, please check out our change log!

        V-Play Game Engine

        Connect with Facebook

        V-Play now lets you connect your matchmaking service and leaderboards with Facebook, giving users even more social features.

        The VPlayMultiplayerView for matchmaking and VPlayGameNetworkView for leaderboards now shows a button that allows players to connect to Facebook if a VPlayGameNetwork::facebookItem is configured.

        If players connect with Facebook and give access to their friends list, they can directly compare scores with their Facebook friends. They can also challenge them to multiplayer matches without the hassle of manually searching for their friends in the game. The player profile, which includes scores, achievements and friends, is synchronized if a player uses the same account on multiple devices.

        V-Play Multiplayer

        You can enjoy a number of improvements to the V-Play Multiplayer feature when you update to V-Play 2.10.0. These updates make it easier for players to begin games or join in existing games.

        onecard-game
         

        For example, you can now use the VPlayMultiplayer::invitePlayers() or VPlayMultiplayer::uninvitePlayer() methods to add or remove players while the game is already open.

        You can activate or deactivate player slots with the MultiplayerUser::enabled property or VPlayMultiplayer::enablePlayer() and VPlayMultiplayer::disablePlayer() methods. This allows you to make multiplayer game for 2, 3, or more players.

        V-Play 2.10.0 also lets you customize the random join feature with the new properties VPlayMultiplayer::customFilterProperties and VPlayMultiplayer::filterSqlQuery so players only join rooms that match their set filter.

        These advanced matchmaking options should boost user engagement and retention as these new features give players more control over who they interact with in your game.

        Learn more about V-Play Multiplayer here!

        V-Play Plugins

        The AdMob, Chartboost and Flurry plugin have all been updated by this release. All 3 plugins now use the latest platform SDK’s for iOS and Android. You can learn more about this by visiting the plugin documentation page.

        See the V-Play change log for a full list of the improvements this release brings to V-Play!

        Fixes

        V-Play 2.10.0 includes fixes for V-Play Apps, V-Play Game Engine and V-Play Plugins. The most important fixes involve V-Play Apps and resolve the following issues:

        • Fixes a compatibility issue of AppTabBar with Qt 5.8 that broke the rendering of the tab buttons.
        • Solves issue of AlphaVideo not showing on some Android devices and correctly scales the video when the item size changes.
        • Hidden Dialog and InputDialog instances no longer consume the Android back-button after they are closed.

        You can see all the fixes this update brings by checking out our change log here!

        How to Update V-Play

        Test out these new features by following these steps

        Step 1

        Open the V-Play SDK Maintenance Tool in your V-Play SDK directory. Choose “Update components” and finish the update process to get V-Play 2.10.0 as described in the V-Play Update Guide.

        If you haven’t installed V-Play yet, you can do so now with the latest installer from here.

        Step 2

        The V-Play Sample Launcher allows you to quickly test and run all the open-source examples and demo apps & games that come with the V-Play SDK, from a single desktop application.

        sample launcher

        After installing V-Play, you can start the V-Play Sample Launcher from the application shortcut in your V-Play SDK directory.

        Now you can explore all of the new features included in V-Play 2.10.0!

        For a complete list of the changes to V-Play with this update, please check out our change log!

        NOTE: Please see the paragraph above on how to successfully update to Qt 5.8 for V-Play. Some additional steps are required!

        More Posts like This

        20 Free & Secure Alternatives to the Parse Push Service

        parse-plugin

        The 13 Best Qt, QML & V-Play Tutorials and Resources for Beginners

        tutorials capture

        21 Tips That Will Improve Your User Acquisition Strategy

        User Acquisition

        7 Useful Tips That Will Improve Your App Store Optimization

        User Acquisition

        The post Release 2.10.0: New App Showcase, Multiplayer & Multi-Language Improvements, Qt 5.8 appeared first on V-Play Engine.

        Qbs 1.7 released

        We are delighted to announce the release of Qbs 1.7 “Technical Ecstasy”!

        While Qbs 1.7.0 was actually released back in mid-December, we decided to postpone the announcement until after last week’s 1.7.1 patch release in order to get in a few more bug fixes.

        What’s new?

        In addition to lots of bugfixes and smaller improvements, as well as some significant performance enhancements, this release also brings a number of new features. Let’s start with the largest and most interesting:

        Generators

        Generators are a major new feature in Qbs 1.7 that enables deep integration with your favorite third-party development tools.

        The Generators API is designed to be very generic. It provides a means for developers to create “plugins” that perform arbitrary processing on the build graph. So, far we’ve used this to create several generators which output Xcode* and Visual Studio project files. This allows you to develop your projects in your favorite IDE, while still retaining the full power and expressibility of the Qbs build engine.

        We’ve also received a community contribution that outputs a Clang compilation database file. This allows Clang-based tools to scan the sources exactly like the compiler, independently of the build system. We’re excited to see what other generators the community might come up with.

        To get started with generators, try the qbs generate command on your project. The generators documentation will be available in the manual in a future release.

        Note that the generators features are still very experimental. We will greatly appreciate your feedback in this area.

        the Xcode generator is scheduled for release in Qbs 1.8

        Other new features

        • Group items can now be nested. This allows Groups to be structured more naturally, as a Group’s condition property is logically ANDed with its parent’s. It also makes Groups more useful when placed into dedicated files as the inherited QML-like syntax requires a root element.
        • qrc files can be automatically generated from your project file, obviating the need to manually maintain multiple identical file lists. This functionality is part of the Qt.core module and introduces a couple of new properties which allow you to control how files in your project should be automatically added to a generated qrc file.
        • There is now much more complete documentation on Rule authoring. This has been one of our biggest requests in the documentation area.
        • Stricter type checking for properties in Qbs project files, which should help make certain syntax errors much clearer.
        • Microsoft Visual Studio 2017 support in the C/C++ module.
        • QtScxml support in the Qt modules.
        • Support for building Inno Setup installers.

        One last thing worth mentioning is that the Open Source C++ package manager Conan has added support for Qbs. We believe integrations like this which make it easier to integrate third-party content with your projects are a great ecosystem boon.

        Try It!

        The Open Source version is available on the download page, and you can find commercially licensed packages on the Qt Account Portal. Please post issues in our bug tracker. You can also find us on IRC on #qt-qbs on chat.freenode.net, and on the mailing list. The documentation and wiki are also great places to get started.

        Qbs is also available on most major packaging systems (Chocolatey, MacPorts, Homebrew) and updated on each release by the Qbs development team. It can also be installed through the native package management system on a number of Linux distributions including but not limited to Debian, Ubuntu, and Arch Linux.

        Qbs 1.7.1 is also included in Qt Creator 4.2.1, which was released last week.

        The post Qbs 1.7 released appeared first on Qt Blog.

        New QtLabs PDF module

        A couple of years ago during a hackathon, a couple of us wrote a Qt wrapper around PDFium, the open-source PDF rendering engine which is used for viewing PDFs in Chromium.  There have been a few fixes and improvements since then.  Now we (finally) have made this module available under the LGPLv3 license.

        QPdfDocument can render a PDF page to a QImage, and there is QPdfBookmarkModel which can be used for a bookmarks view. There is an example application: a widget-based PDF viewer.

        If you want to try it out, here’s how to get started:

        git clone git://code.qt.io/qt-labs/qtpdf
        cd qtpdf
        git submodule update --init --recursive
        qmake
        make
        cd examples/pdf/pdfviewer
        qmake
        make
        ./pdfviewer /path/to/my/file.pdf
        

        qtpdf-example
        There is some work in progress to add support for PDF in QtQuick, to treat it as an ordinary image format and to add support for multi-page image formats in general, but we don’t have any particular target release date yet.

        The post New QtLabs PDF module appeared first on Qt Blog.

        What’s New in Qt on Apple Platforms

        Note that throughout this blog post, the term “Apple Platforms” will be used to refer to all four Apple operating systems (macOS, iOS, tvOS, and watchOS) as a whole.

        I thought it would be a good time to share some of the highlights of what’s new in Qt on Apple Platforms with the recent release of Qt 5.8.

        New Platforms

        To start off, Qt now has Technology Preview level support for Apple TV and Apple Watch devices beginning in Qt 5.8. This completes our offering to support all four Apple Platforms – macOS, iOS, tvOS, and watchOS.

        tvOS (Apple TV)

        Qt for tvOS is 95% similar to iOS (even the UI framework is also UIKit) and as a result, contains roughly the same feature set and supported modules as iOS, with the notable exception of QtWebEngine.

        The major difference between the two platforms is input handling. iOS has a touch-based model that maps fairly well to a traditional point and click desktop interface from a programming perspective, while tvOS has a focus based model. This means that you don’t have a canvas which can receive input at a particular point (x,y coordinate), but rather an abstract canvas in which you “move” the focus to a particular object. When an object has focus, you can use the Apple TV Remote to trigger an action by clicking its trackpad or pressing the Menu or Play/Pause buttons.

        Qt supports some aspects of the tvOS input model (scrolling and clicking are recognized), but there will be some degree of manual work handling input events in QML to build a tvOS app. Most basic navigation actions on the Apple TV Remote are exposed as keyboard events in Qt, and gesture recognizers can be used for more complex multitouch input. We are still exploring ways to provide mechanisms that make it easier to work with this new input model.

        We’d also like to thank Mike Krus doing the initial work of porting Qt to tvOS, and who is now the platform’s maintainer.

        watchOS (Apple Watch)

        Qt for watchOS is also heavily based on iOS. However, it is not possible to run QML or any other Qt based UI on the watch using public APIs because the primary interface API is WatchKit (as opposed to UIKit). Therefore, Qt can currently only be used for non-UI tasks such as networking, audio, backend graphics processing, etc. If the available watchOS APIs change in the future then we can certainly explore the possibilities at that point.

        I am also the watchOS platform maintainer, so please feel free to send me any questions or feedback.

        Shared Libraries on iOS

        Only static libraries were permitted for most of iOS’s existence, as many iOS developers are no doubt aware. Apple’s App Store requirements prohibited shared libraries even though the underlying operating system supported them since 1.0. Finally, with the release of iOS 8 and Xcode 6 in 2014, shared libraries/frameworks became officially supported by Apple for use in applications submitted to the App Store. Unfortunately, while this feature did not make it in time for the Qt 5.8 release… Qt 5.9 will support them too (also for tvOS and watchOS)!

        To build Qt as shared libraries on iOS, all you need to do is pass the -shared option to configure (and this will be the default in the next release). Note that shared libraries require a deployment target of at least iOS 8.0, which will also be the minimum requirement for Qt 5.9.

        With shared libraries, you can simplify your development workflow by not having to maintain separate code paths for static libraries on iOS and shared libraries on other platforms. Shared libraries also allow you to:

        • When using App Extensions (as both your main application and your extension executables may link to the same copy of the Qt frameworks), reduce memory consumption and reduce disk space consumption on your users’ devices as your app will be smaller
        • Make your code base easier to maintain through strict API boundaries and the benefits of namespacing
        • Speed up linking and thus overall build time

        Because the question will inevitably come up: we do not believe shared libraries will have any practical effect for LGPL users. There are other concerns that come into play with the Apple App Store (namely, DRM) which render the point moot. However, we recommend using shared libraries for the technical reasons outlined above. And as always, seek professional legal advice with regard to software licensing matters.

        Build System Enhancements

        In the past several Qt releases we have also made a number of significant enhancements to the build system on Apple Platforms, including:

        • @rpath in the install names of Qt libraries, providing relocatability out of the box (Qt 5.5)
        • Standalone .dSYM debug symbols (Qt 5.6.1, Qt 5.6.2)
        • Building asset catalogs (Qt 5.6.3 & Qt 5.7.1)
        • Bitcode on iOS which allows Qt applications to take advantage of App Thinning (Qt 5.8)
        • Precompiled headers on iOS, tvOS, and watchOS, reducing build time by up to 30% (Qt 5.8)
        • Combined simulator and device builds, doing away with the confusing separate _simulator libraries on iOS (Qt 5.8)
        • Multi-arch (“universal”) builds on macOS, back from Qt 4.x (coming in Qt 5.9)
        • Automatically embedding Qt frameworks within a Qt app bundle in qmake-generated Xcode projects (coming in Qt 5.9)
        • …and many other smaller bug fixes

        One more thing… we’ve been changing every reference to “Mac OS X” and “OS X” that we can find into “macOS”. 🙂

        The post What’s New in Qt on Apple Platforms appeared first on Qt Blog.

        Qt Visual Studio Tools Insights

        While working on the Qt Visual Studio tools, I had to think about how to locally perform and test the update process for extensions. As already known to most Visual Studio users, the IDE provides a way to setup your own private extension gallery. To do so, one has to open the Visual Studio Tools | Options Dialog and create a new Additional Extension Gallery under Environment | Extensions and Updates.

        My initial try was to simply put the generated VSIX into a folder on the disk and point the URL field to this folder. After looking at the Tools | Extensions and Updates dialog, no update was highlighted for the tools. Because this was not as easy as I had thought, so some configuration file probably needed to be provided. A short search on the Internet led to the following article – there we go, it turned out that the configuration file is based on the Atom feed format.

        Visual Studio uses an extended version of the Atom feed format consisting of two parts, the Header and the Entry. The header needs to be provided only once, while the entry can be repeated multiple times. Lets take a look at the header tags:

        <title> The repository name.
        <id> The unique id of the feed.
        <updated> The date/time when the feed was updated.

        Please note that even though these tags do not seem to be important for the desired functionality, it still makes sense to keep them.

        The more interesting part is the Entry tag that describes the actual package you’re going to share. There seem to be a lot of optional tags as well, so I’m just going to describe the most important one. To force an update of your package, simply put an <Vsix> inside the entry tag. It must contain two other tags:

        <id> The id of your VSIX.
        <version> The version of the VSIX.

        As soon as you increase the version number, even without rebuilding the VSIX, Visual Studio will present you with an update notice of your package. For a more advance description of the tags possible, follow this link. If you are looking for the minimum Atom feed file to start with, you can grab a copy of ours here.

        So now one might ask, why did I write all that stuff? Well, while I was preparing the next Qt Visual Studio Tools release I scratched my head quite a bit on this topic. And just maybe – it might save some other developer’s day while doing a Visual Studio extension release. Last but not least, I am happy to announce the availability of an updated version of the Qt Visual Studio Tools with the following improvements:

        • Bug fixes
        • Making it faster
        • Using the new TextMate language files in Visual Studio 2015 SP3 for QML file and QMake project file syntax highlighting

        The Qt Company has prepared convenient installers for the Qt Visual Studio Tools 2.1 release. You can download it from your Qt Account or from download.qt.io. They are also available from the Visual Studio Gallery for Visual Studio 2013 and Visual Studio 2015.

        For any issues you may find with the release, please submit a detailed bug report to bugreports.qt.io (after checking for duplicates). You are also welcome to join the discussions in the Qt Project mailing lists, development forums and to contribute to Qt.

        The post Qt Visual Studio Tools Insights appeared first on Qt Blog.

        gbgcpp

        Another interesting weeks has passed by. We held our first Gothenburg C++ meetup with a nice turn up. We met at the Pelagicore offices in Gothenburg (thanks for the fika) and decided on a format, the cadence and future topics for the group. If you want a primer in C++ and Qt in the next few months, make sure to join us! All the details are on the gbgcpp meetup page. For those of you not based in Gothenburg, there is a Sweden C++ group based in Stockholm.

        Some other, more work related news: Pelagicore are changing offices in Gothenburg and it will be an Upgrade with a capital U! We’ve signed for a really nice office space just across the street from the opera and less than five minutes from the central train station and the Brunnsparken public transport hub of Gothenburg. And as always – we are looking for developers – hint, hint ;-)

        Finally, do not forget that fosdem starts in a week. I’m going, so I’ll see you in Brussels!

        OpenGL Core Profile Context support in QPainter

        As many of you may know, QPainter has a multi-backend architecture and has two main paint engine implementations under the hood in Qt 5: the raster paint engine and the OpenGL2 paint engine, designed for OpenGL ES 2.0.

        The GL Paint Engine

        While in many ways the raster paint engine can be considered one of Qt’s crown jewels, let’s now talk about the other half: the GL paint engine that is used when opening a QPainter on

        The Problem

        What about modern OpenGL, though?

        That is where the problems started appearing: around Qt 5.0 those who were in need of a core profile context due to doing custom OpenGL rendering that needed this ended up running into roadblocks quite often. Components like Qt Quick were initially unable to function with such contexts due to relying on deprecated/removed functionality (for example, client-side pointers), lacking a vertex array object, and supplying GLSL shaders of a version the support for which is not mandated in such contexts.

        In some cases opting for a compatibility profile was a viable workaround. However, Mac OS X / macOS famously lacks support for this: there the choice has been either OpenGL 2.1 or a 3.2+ core profile context. Attempts to work this around by for instance rendering into textures in one context and then using the texture in another context via resource sharing were often futile too, since some platforms tend to reject resource sharing between contexts of different version/profile.

        Progress

        Fortunately, during the lifetime of Qt 5 things have improved a lot: first Qt Quick, and then other, less user-facing GL-based components got fixed up to be able to function both with core and compatibility contexts.

        As of Qt 5.8 there is one big exception: the GL paint engine for QPainter.

        The Last Missing Piece

        The good news is, this will soon no longer be the case. Thanks to a contribution started by Krita, see here for some interesting background information, QPainter is becoming able to function in core profile contexts as well. Functionality-wise this will not bring any changes, rendering still happens using the same techniques like before.

        In addition to fixing up the original patch, we also integrated it with our internal QPainter regression testing system called Lancelot. This means that in addition to raster (with various QImage formats) and OpenGL 2, there will also be a run with a core profile context from now on, to ensure the output from QPainter does not regress between Qt releases.

        All in all this means that a snippet like the following is now going to function as expected.

          class Window : public QOpenGLWindow {
            void initializeGL() override {
              QSurfaceFormat fmt;
              fmt.setVersion(4, 5); // or anything >= 3.2
              fmt.setProfile(QSurfaceFormat::CoreProfile);
              setFormat(fmt);
            }
            void paintGL() override {
              QPainter p(this);
              p.fillRect(10, 10, 50, 50, Qt::red);
              ...
            }
            ...
          };
        

        When?

        Qt 5.9.

        The patch has now been merged to qtbase in the ‘dev’ branch. This will soon branch out to ‘5.9’, which, as the name suggests, will provide the content for Qt 5.9. Those who are in urgent need of this can most likely apply the patch (see QTBUG-33535) on top of an earlier version – the number of conflicts are expected to be low (or even zero).

        That’s all for now, have fun with QPainter in core profile contexts!

        The post OpenGL Core Profile Context support in QPainter appeared first on Qt Blog.

        Un-deprecate your Qt project

        The last post from my colleague Marc Mutz about deprecating Q_FOREACH caused quite an uproar amongst the Qt developers who follow this blog. I personally feel that this was caused fundamentally by a perceived threat: there is a cost associated to porting away a codebase from a well-known construct (Q_FOREACH) to a new and yet-undiscovered […]

        The post Un-deprecate your Qt project appeared first on KDAB.

        Stepanov-Regularity and Partially-Formed Objects vs. C++ Value Types

        In this article, I will take a look at one of the fundamental concepts introduced in Alex Stepanov and Paul McJones’ seminal book “Elements of Programming” (EoP for short) — that of a (Semi-)Regular Type and Partially-Formed State. Using these, I shall try to derive rules for C++ implementations of what are commonly called “value […]

        The post Stepanov-Regularity and Partially-Formed Objects vs. C++ Value Types appeared first on KDAB.

        Connecting your Qt application with Google Services using OAuth 2.0

        With the Qt 5.8 release, we have added QtNetworkAuth as a Technology Preview module. It is focused on helping developers with this auth******** madness. Currently, it supports OAuth1 and OAuth2. In the future, it will feature more authorization methods.

        This post is a first glance of the OAuth2 support in Qt, it covers how to use Google to authorize an application. Your application will be able to show the typical log-in/authorize app screen, just like a web application (NOTE: A browser or a webview is needed):

        .

        The IETF defines OAuth 2.0 as:

        The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf.

        OAuth authorization is also a requirement to use the Google APIs and access user information stored in Google Services like Gmail, Drive, Youtube, Maps, and others.

        If you are interested in how to create an application using OAuth2, please continue reading.

        Register your new project

        Before start writing code, you need to register a new project in the service provider. This step is necessary because you have to request the client credentials to identify your application. The following steps are based on Google API Console but they are similar to other providers.

        Creating new project

        To start the project registration, access Google API Console, then, press “Create Project”.

        spectacle-t26843

        A “New Project” dialog appears. Type the name of your project and click the “Create” button. Now you are ready to manage your new project.

        spectacle-g26843

        Your application is registered, the dashboard is updated and you can set different options from this screen.

        spectacle-a26843

        Creating the credentials

        You have to get credentials to identify the application. Go to the “Credentials” section in the dashboard and press the “Create credentials” button. You need to choose which type of credentials you need. Choose “OAuth client ID”.

        spectacle-x26843

        In the next screen, you can configure a “consent screen” with your Email address, product name, homepage, product logo, … Fill it with your data and press the “Save” button.

        Go back to the previous “Create client ID” screen to choose the “Application type”. Different options are available here; you need to choose “Web application”. Give it a name.

        spectacle-r26843

        Under “Restrictions” there is an important field: the “Authorized redirect URIs”.

        If the user chooses to allow your application to manage his data. The application has to receive an “access token” to be used during authenticated calls. The “access token” can be received in several ways, but the most common way is to receive a call to your web server with the “access token”. In web applications, a server path to handle the notification is enough. A desktop application need to fake it using a local browser.

        Add a URI accessible by your Internet browser including the port if you are using a different one than 80. When the application is running, a basic HTTP server will receive information from the browser.

        Most of the times you need to use a URI like: “http://localhost:8080/cb”.

        NOTE: The path “/cb” is mandatory in the current QOAuthHttpServerReplyHandler implementation.

        NOTE: You can configure different URIs. In this example, a single URI is assumed.

        End the process by pressing the “Create” button and you will see a new credential in the list of credentials with an “Edit”, “Delete” and “Download” buttons at the right. Click the download button and… Finally, you get a JSON file ready to parse!

        spectacle-m27458

        In the screenshot above you can see some new URIs and the client_id and the client_secret. There is no need to use the JSON file, you can hardcode this information directly in your application.

        Writing the Google API Wrapper code

        I will omit the part of defining the class and show the relevant code.

        In your code create a QOAuth2AuthorizationCodeFlow object:

        auto google = new QOAuth2AuthorizationCodeFlow;
        
        

        Configure the scope you need to access from the application. The scope is the desired permissions the application needs. It can be a single string or a list of strings separated by a character defined by the provider. (Google uses the space character as separator).

        NOTE: The scopes are different depending on the provider. To get a list of scopes supported by Google APIs click here.

        Let’s use the scope to access the user email:

        google->setScope("email");
        
        

        Connect the authorizeWithBrowser signal to the QDesktopServices::openUrl function to open an external browser to complete the authorization.

        connect(google, &QOAuth2AuthorizationCodeFlow::authorizeWithBrowser,
            &QDesktopServices::openUrl);
        
        

        Parse the downloaded JSON to get the settings and information needed. document is an object of type QJsonDocument with the file loaded.

        const auto object = document.object();
        const auto settingsObject = object["web"].toObject();
        const QUrl authUri(settingsObject["auth_uri"].toString());
        const auto clientId = settingsObject["client_id"].toString();
        const QUrl tokenUri(settingsObject["token_uri"].toString());
        const auto clientSecret(settingsObject["client_secret"].toString());
        const auto redirectUris = settingsObject["redirect_uris"].toArray();
        const QUrl redirectUri(redirectUris[0].toString()); // Get the first URI
        const auto port = static_cast<quint16>(redirectUri.port()); // Get the port
        

         

        After parsing the file configure the google object.

        google->setAuthorizationUrl(authUri);
        google->setClientIdentifier(clientId);
        google->setAccessTokenUrl(tokenUri);
        google->setClientIdentifierSharedKey(clientSecret);
        
        

        Create and assign a QOAuthHttpServerReplyHandler as the reply handler of the QOAuth2AuthorizationCodeFlow object. A reply handler is an object that handles the answers from the server and gets the tokens as the result of the authorization process.

        auto replyHandler = new QOAuthHttpServerReplyHandler(port, this);
        google->setReplyHandler(replyHandler);
        
        

        The grant function will start the authorization process.

        google->grant();
        
        

        If everything was OK, you should receive a QOAuth2AuthorizationCodeFlow::granted signal and start sending authorized requests.

        You can try sending a request using https://www.googleapis.com/plus/v1/people/me

        auto reply = google->get(QUrl("https://www.googleapis.com/plus/v1/people/me"));
        

         

        It will give you a QNetworkReply and when QNetworkReply::finished is emited you will be able to read the data.

        To be continued…

        The post Connecting your Qt application with Google Services using OAuth 2.0 appeared first on Qt Blog.

        Cutelyst 1.3.0 released

        Only 21 days after the last stable release and some huge progress was made.

        The first big addition is a contribution by Matthias Fehring, which adds a validator module, allowing you to validate user input fast and easy. A multitude of user input types is available, such as email, IP address, JSON, date and many more. With a syntax that can be used in multiple threads and avoid recreating the parsing rules:

        static Validator v({ new ValidatorRequired(QStringLiteral("username") });
        if (v.validate(c,Validator::FillStashOnError)) { ... }

        Then I wanted to replace uWSGI on my server and use cutelyst-wsgi, but although performance benchmark shows that NGINX still talks faster to cutelyst-wsgi using proxy_pass (HTTP), I wanted to have FastCGI or uwsgi protocol support.

        Evaluating FastCGI vs uwsgi was somehow easy, FastCGI is widely supported and due a bad design decision uwsgi protocol has no concept of keep alive. So the client talks to NGINX with keep alive but NGINX when talking to your app keeps closing the connection, and this makes a huge difference, even if you are using UNIX domain sockets.

        uWSGI has served us well, but performance and flexible wise it's not the right choice anymore, uWSGI when in async mode has a fixed number of workers, which makes forking take longer and user a lot of more RAM memory, it also doesn't support keep alive on any protocol, it will in 2.1 release (that nobody knows when will be release) support keep alive in HTTP but I still fail to see how that would scale with fixed resources.

        Here are some numbers when benchmarking with a single worker on my laptop:

        uWSGI 30k req/s (FastCGI protocol doesn't support keep conn)
        uWSGI 32k req/s (uwsgi protocol that also doesn't support keeping connections)
        cutelyst-wsgi 24k req/s (FastCGI keep_conn off)
        cutelyst-wsgi 40k req/s (FastCGI keep_conn on)
        cutelyst-wsgi 42k req/s (HTTP proxy_pass with keep conn on)
        

        As you can see the uwsgi protocol is faster than FastCGI so if you still need uWSGI, use uwsgi protocol, but there's a clear win in using cutelyst-wsgi.

        UNIX sockets weren't supported in cutelyst-wsgi and are now supported with a HACK, yeah sadly QLocalServer doesn't expose the socket description, plus another few stuff which are waiting for response on their bug reports (maybe I find time to write and ask for review), so I inspect the children() until a QSocketNotifier is found and there I get it. Works great but might break in future Qt releases I know, at least it won't crash.

        With UNIX sockets command line options like --uid, --gid, --chown-socket, --socket-access, as well as systemd notify integration.

        All of this made me review some code and realize a bad decision I've made which was to store headers in lower case, since uWSGI and FastCGI protocol bring them in upper case form I was wasting time converting them, if the request comes by HTTP protocol it's case insensitive so we have to normalize anyway. This behavior is also used by frameworks like Django and the change brought a good performance boost, this will only break your code if you use request headers in your Grantlee templates (which is uncommon and we still have few users). When normalizing headers in Headers class it was causing QString to detach also giving us a performance penalty, it will still detach if you don't try to access/set the headers in the stored form (ie CONTENT_TYPE).

        These changes made for a boost from 60k req/s to 80k req/s on my machine.

        But we are not done, Matthias Fehring also found a security issue, I dunno when but some change I did break the code that returned an invalid user which was used to check if the authentication was successful, leading a valid username to authenticate even when the logs showed that password didn't match, with his patch I added unit tests to make sure this never breaks again.

        And to finish today I wrote unit test to test PBKDF2 according to RFC 6070, and while there I noticed that the code could be faster, before my changes all tests were taking 44s, and now take 22s twice as fast is important since it's a CPU bound code that needs to be fast to authenticate users without wasting your CPU cycles.

        Get it! https://github.com/cutelyst/cutelyst/archive/r1.3.0.tar.gz

        Oh and while the FreeNode #cutelyst IRC channel is still empty I created a Cutelyst on Google groups: https://groups.google.com/forum/#!forum/cutelyst

        Have fun!

        Qt 5.8 released

        I am happy to announce that Qt 5.8 has been released today and is available for download from qt.io. Qt 5.8 does of course come with Qt Creator 4.2.1 and an update to Qt for Device Creation. Qt 5.8 is a rather large release, containing quite a large set of new functionality. Let’s have a look at some of them:

        Qt Lite

        One of the main themes of Qt 5.8 has been to make Qt more flexible and easier to adopt to your use case, targeted especially at our embedded users. Qt Lite has been the codename of the project under which we did those changes.

        Our goal has been to make it easier to configure Qt to exactly your needs and leave out features that you don’t need in your project. This brings major savings in the size of the compiled Qt libraries and thus your application.

        Implementing support for this put us on a longer journey, where we rewrote most parts of the system that was being used to configure Qt. The new system cleans up a system that had grown over the last 15 years, and that also lead to many inconsistencies on how Qt was being configured on different host platforms.

        As a result, we now have one unified system to configure the different parts of Qt. In addition to giving our users a lot more flexibility in configuring Qt, it will also ease our burden in supporting all the different ways Qt can be configured and used.

        Using the new system allows you to create a Qt build tailored to exactly your use case. You can leave out all the features in Qt that you don’t need, saving ROM and RAM when deploying to your embedded device. To give you an idea of the size savings possible, the image below shows the size of the required Qt stack to run a small QML application:

        Size of sample app using Qt 5.6 and a lite configuration of Qt 5.8

        As you can see, the new configuration system allows for significant reductions in size and savings of more than 60% in binary size compared to Qt 5.6.

        Qt Wayland Compositor

        The Qt Wayland Compositor API that we included as a Technology Preview in Qt 5.7 is now fully supported in Qt 5.8. The module makes it very easy to create your own Wayland Compositor.

        Qt Wayland Compositor make it very easy to implement your own custom home screen and application manager. This allows the creation of powerful and more complex embedded systems where you have multiple applications that have their own user interfaces. Qt Wayland Compositor supports handling multiple screens in an easy and transparent way. It comes with both QML and C++ APIs.

        For more details, have a look at the API documentation and examples, as well as this blog post, which also features a tutorial.

        Communication and Networking

        Qt Serialbus has now graduated to be fully supported in Qt 5.8. It allows you to use Qt APIs for device bus communications and protocols. While the API is rather generic, this version includes implementations for CAN and Modbus.

        Qt Network and Web Sockets gained full support for TLS PSK cyphersuites. Qt Network now supports configurable Diffie-Hellman parameters and HTTP/2 in QNetworkAccessManager.

        Qt Bluetooth gains BTLE Peripheral support on macOS and iOS as well as BTLE Central support on WinRT.

        Qt 5.8 also adds a new Qt Network Authorization module as a Technology Preview, currently supporting the OAuth 1 and 2 authentication schemes.

        Qt QML and Quick

        Quite a few things have happened in Qt QML and Qt Quick. The QML engine has gained support for caching binary representations of QML and JS files on disk, reducing startup time and memory consumption of the engine. The commercial only Qt Quick compiler is still supported in 5.8, but we are planning to merge it with the new caching infrastructure in the future, leading to a better performing and more tightly integrated solution.

        The Qt Quick scene graph has undergone a larger refactoring, making it less dependent on OpenGL. This allowed us to add an experimental Direct3D 12 backend for Qt Quick, and does enable the creation of other backends e.g. based on the Vulkan graphics APIs.

        In addition, the scene graph now supports partial updates to the screen if only a small area of the scenography changed. This brings some larger performance improvements to the Qt Quick 2D renderer.

        We also used the changes to the scene graph as an opportunity to fold the functionality of the Qt Quick 2D renderer into Qt Quick directly. This implies that the Qt Quick 2D renderer does not exist as a standalone module in Qt 5.8 anymore.

        Larger changes have also been done under the hood with respect to Mouse and Touch event handling, unifying them internally in a new QQuickPointerEvent class. This lays the foundation for future improvements to mouse and touch event handling, but doesn’t affect code using Qt Quick yet.

        The Qt Quick Controls 2 have also gained a couple of new types such as dialogs, rounded buttons and tool separators. The Material and Universal styles have gained some new effects and support for a ‘system’ theme.

        Qt Webengine

        As always the Chromium version used by Qt Webengine has been updated, this time to Chromium 53. One long outstanding feature added in Qt 5.8 is the ability to print web pages. Many smaller new features have been added, amongst them a new QML API to define custom dialogs, tootips and context menus, and support for view-source: and some chrome: schemes.

        Qt SCXML

        Qt SCXML is now fully supported in Qt 5.8. The module makes is trivial to integrate SCXML based state machines into Qt. It builds directly onto the Qt Statemachine Framework, and extends it with with both a SCXML to C++ compiler and a runtime that allows loading SCXML based state machines.

        Together with the Qt SCXML module, Qt Creator 4.2 gained support for editing state charts.

        New Technology Previews

        Also in Qt 5.8, we have new functionality that we chose to introduce as a Technology Preview.

        Qt now compiles for both Apple’s tvOS and watchOS. While most of the functionality that we support on iOS should also work on tvOS, watchOS support is limited to the non-graphical functionality in Qt.

        Qt Speech has been added as a new module adding support to text to speech functionality.

        Other improvements

        After the initial release of Qt 3D with Qt 5.7, the focus for 5.8 has been on maturing the module. A large amount of bug fixes and performance improvements have been made for the module.

        Qt Charts has gained a Candlestick chart type and we have made the QOpenGLTextureBlitter API in Qt Gui public.

        Our embedded platforms supported by Qt for Device Creation have gained better support for multi-screen systems when using the eglfs QPA plugin and support for 90/180 degree rotated screens.

        Finally, many changes happened to our code base to make better use of the new features offered by C++11 and with that clean up and modernize our code base.

        Thanks to the Qt Community

        Qt 5.8 adds a lot of new functionality and improvements. Some of them would not have been possible without the help of the great community of companies and people that contribute to Qt by contributing new functionality, bug fixes, documentation, examples or bug reports. Thank you!

        You can read more about the release and watch our launch video here, get Qt 5.8 from your Qt Account or www.qt.io/download. I hope you’ll like and enjoy the new release!

        The post Qt 5.8 released appeared first on Qt Blog.

        Qt SCXML and State Chart Support in Qt Creator

        Qt has provided support for state machine based development since introduction of Qt State Machine Framework in Qt 4.6. With the new functionality introduced in Qt 5.8 and Qt Creator 4.2 state machine based development is now easier than ever before.

        Qt 5.8 introduces fully supported Qt SCXML module that makes it easy to integrate SCXML based state machines into Qt. Previously SCXML has been imported to Qt from external tools, which is still possible. Now Qt Creator 4.2 introduces a new experimental visual state chart editor that allows creation and modification of state charts directly with Qt Creator IDE. Together with the new editor and other improvements in Qt Creator, state machine based development can be done completely within Qt Creator.

        Here is a short screen cast that shows these new features in action. For demonstration purposes, the simple state machine driven example application with Qt Quick user interface Traffic Light is being recreated from scratch.

        Note that the the editor is still experimental with Qt Creator 4.2 and the plugin is not loaded by default. Turn it on in Help > About Plugins (Qt Creator > About Plugins on macOS) to try it.

        The post Qt SCXML and State Chart Support in Qt Creator appeared first on Qt Blog.