A Release Candiate for Swift 4.0 is now available for download. Read on for more information and download instructions.

Swift 4.0 RC2 is now available from our releases page. This release includes:

• Support for message carbons (XEP-0280)
• Trellis mode enabled as a default feature, allowing several tiled chats windows to be shown at once
• New chat theme including a new font
• Redesigned keyword highlighting
• Improved spell checker support on Linux
• Support for automatic software updates on macOS
• Support for unicode emojis on macOS
• And assorted smaller features and usability enhancements

Please email (swift@swift.im) or tweet (@swift_im) any feedback you have to help us further improve Swift.

Qt Lite has been our project name for multiple efforts done to approach to a more salable Qt version. We introduced this first in Qt 5.8, earlier this year, and are extremely happy to see all the use cases and new opportunities this has unlocked for Qt. It is now far easier than before to build a small and tailored version of Qt for your specific need.

We have added a lot of new configuration options in Qt 5.9 LTS, and updated the corresponding Qt Configuration UI Tool to take this into account.  The configuration tool list all the options available, and provides simple and easy access to all the new configuration options. This way, you do not have to learn all the ins and outs of each module, to generate a meaningful and optimized version of that module. For the time being, the Configuration UI Tool is a commercial only tool, that adds value for our Device Creation customers.

There hundreds of  individual configuration options, ranging from major features like OpenGL support, to minor details in Qt. Qt Lite covers features in all our core libraries, Networking, SQL, Qt GUI, Qt QML, Qt Quick, XML, Widgets, Connectivity, Qt Gamepad, Location and Positioning, Multimedia, Sensors, Serialbus, Wayland Client and Compositor, Bluetooth, XML Patterns, as well as the Qt WebEngine, and more. Qt Lite thus allow you to disable features that are not used in your application, even though you still want other features available in the modules they have been implemented. Moving a way from a completely monolithic approach has been very beneficial, and we hope this can continue to benefit all our users.

One example of this is the implementation of Samegame, a non trivial Qt Quick based game. In Qt 5.6 LTS, the statically linked application and libraries all of 13.8MB, but using Qt Lite configuration options, we are able to create a more than 60% smaller deployable binary with Qt 5.9 LTS.

As Qt continues to grow, and add more features, we see this as an important mechanism of maintaining a framework that will fit with the needs of the embedded industry. In line with this, Qt 5.9 is the first release in which we officially support the new iMX7 architecture from NXP; and without OpenGL and targeted at the wearables market Qt lite provides an excellent way of deploying to this target.

Qt Lite has been happening along two axes, one part focusing on the configuration system of Qt, and the other making other improvements to Qt to make it perform better in a constrained environment.

To that end we are also adding improvements such as the better utilization of optimization flags. Release builds can achieve a significant further reduction in size from 5-20 percent, by utilizing -Os (with gcc/clang) or -O1 (MSVC). This is enabled with the Qt configuration flag -optimize-size.

Together with the work we do to optimize Qt Quick code, the improvements of Qt Quick Controls for embedded targets, the new OpenVG back end for the improved Scene Graph and all the other efforts in Qt 5.9, these improvements make Qt 5.9 the best choice for any new Device Creation project. And on top of that, it will be supported for a long time, as and LTS release. We hope to see all the cool things that you have been doing with it, and that we can make your product development faster, simpler and more fun. If you want to get started with Qt Lite in 5.9LTS, do not hesitate to contact us if you need support or consulting.

The post Qt Lite in Qt 5.9 LTS appeared first on Qt Blog.

Creating multi-process UIs is a requirement for a broad range of systems across many industries, and there are a variety of use cases available. Everything from fully leveraging your hardware in a digital automotive cockpit — unifying the user experience across all screens on a single SoC, through to separating out critical safety features in medical devices and ensuring safe third-party updates for set-top boxes and digital TVs. Qt Wayland helps you create multi-process user interfaces which support complex architectures.

Recently, we have put a lot of effort into Qt Wayland and the purpose of this blog is to provide a summary of all the content pieces that have been created in recent times. We hope this may entice your interest to add a window compositing system in your next project.

Multi-screen demo for Automotive

At Embedded World 2017 one of our showcases was a multi-screen demo featuring a digital instrument cluster and infotainment system (IVI). To create the multi-process architecture, it uses the application manager based on Qt Wayland in the Qt Automotive Suite. This demo gives you a good idea of how a system with multiple UI processes can look.

Qt Wayland for Agriculture with CLAAS E-Systems

CLAAS E-Systems, part of the CLAAS Group, which is one of the leading manufacturers of harvesters and tractors, quickly adopted Qt Wayland. We have been in contact with Andreas Cord-Landwehr from CLAAS, who stressed that the complexity for automotive was nothing compared to the complexity that he experiences within the field of agriculture. He was more than willing to write a blog to tell his story of how Qt Wayland allowed them to improve their UIs and UX for their machinery. Read the blog to learn more about his experiences with Qt Wayland. 

Creating devices with multiple UI processes using Wayland

One of our main developers for Qt Wayland, Johan Helsing, wrote a blog post in conjunction with our release of the Qt Wayland Compositor API in 5.8, where he explained some of the benefits of creating multi-process user interfaces, as well as why and how it can support your project. He also created a video tutorial on how to create a compositor. Read the blog and watch the tutorial and also check out his on-demand webinar — Creating Devices with multiple UI processes.

Qt from git on the Tinkerboard (with Wayland)

Laszlo Agocs, one of our senior software engineers, conducted a test using an Asus Tinkerboard and set up the latest Qt base and qtdeclarative from the dev branch and tested out Qt Wayland for window compositing. Read more about the project and the results.

There are also more blog posts on this topic available. Contact us if you need support or consulting on how to get started.

The post Multiple UI processes with Qt Wayland – A summary appeared first on Qt Blog.

Designing UIs with buttons, switches, dials, sliders and other UI controls is made easy with Qt Quick Controls and QML. Qt Quick Controls provides ready-made UI controls that speed up the creation of great looking user interfaces. Qt Quick Controls has a selection of built-in styles based on various design guidelines allowing you to create UIs that are familiar to your end-users.  A lot has happened since Qt 5.7, where we introduced the new UI controls focusing on embedded systems and mobile, and the purpose of this blog is to give you a summary of what has happened and provide links to content we have created for the last three releases so that you can gain a better understanding of how the Qt Quick Controls can support your project.

Qt 5.7 — Qt Quick Controls 2 launch

In Qt 5.7 we introduced the new Qt Quick Controls 2 which were built from the ground up to improve the performance allowing us to target embedded systems and mobile as well as desktop applications.

Release video

You can read the release blog for Qt Quick Controls 2.0 – a new beginning.

Qt 5.8 — Focus on sought-after desktop features

In 5.8 the focus was back on improving some of the sought-after desktop features such as hover effects, system themes, and experimental native platform types to name a few.

Check out the release blog for the Qt Quick Controls 2.1.

Watch the on-demand webinar “Tips & Trick with Qt Quick Controls 2.1”

Qt 5.9 — Stability, performance, and multi-touch

The focus for the Qt 5.9 release has been to improve stability and performance and create the next go-to release of Qt with long-term support (LTS). On the QML engine, there have been a lot of improvements directly enhancing the performance and stability of the Qt Quick Controls. We have also added new features such as support for multi-touch. To read more about the new features you can get an overview on the wiki page.

Qt 5.10 and beyond

The Qt Quick Controls 2 can be used as is or you can customize them through defining your style in QML, but what if you want to have the Qt Quick Controls styled by a graphic designer? We are currently researching and developing a way where you can use design software such as Photoshop, Illustrator and so on to style the controls without coding QML. With this approach designers and developers can work together on creating stunning user interfaces.

Check out the video from Embedded World showing off the new features:

Also, read the blog post regarding the project and our plans moving forwards.

With that, I hope that this blog served as a good summary of what has happened with Qt Quick Controls 2 since its release with Qt 5.7 and there is also much more information on Qt Quick Controls available on our blog, our YouTube channel and in our documentation. If you are interested in using the Qt Quick Controls 2 for your next project, you can always contact us if you need support on how to get started.

The post Ready-made UI controls with Qt Quick Controls 2 – A summary appeared first on Qt Blog.

Qt 5.9 LTS improves Qt Quick and QML performance significantly, especially with Linux on ARM. We have worked hard to improve the performance in multiple areas: within the QML engine, Qt Quick graphics, QML Compiler and in the Qt Quick Controls, to name some examples. Performance has improved significantly across all areas, with some items being several times faster than with our previous long-term supported release Qt 5.6 LTS.

We are regularly running several different kinds of performance tests to see how the various optimizations work across different platforms. Some of these results are visible at testsresults.qt.io, while some tests have not been automated yet. Whenever possible, we are aiming to optimize the performance of all supported operating systems and CPU architectures. For readability and because Linux on ARM has been an area of particular focus with Qt 5.9 LTS, it is the one discussed in this post. Typically, the other platforms have received roughly similar improvements.

Qt Quick Application Startup Time

Startup time of a Qt Quick application is often critical in the embedded space. This is true for small single-process embedded systems, as well as for more complex multi-process devices. We have offered a commercial-only tool called the Qt Quick Compiler since Qt 5.3 to improve the startup time by leveraging the C++ compiler to compile QML into a normal C++ binary. Between Qt 5.6 LTS and Qt 5.9 LTS, the performance of the QML engine has improved with each new Qt release, resulting in improved application startup time. Qt 5.8 introduced QML caching, which makes second and subsequent runs of the applications to be faster. Qt 5.9 also offers a possibility to pre-populate the cache to reach improved performance already with the first run. With the Qt Quick Compiler, the first run is also already fast.

Each application has unique characteristics so the exact benefit in startup time for using Qt 5.9 LTS and/or the Qt Quick Compiler will vary. Typically, the more QML used, the bigger the improvement is. In Qt 5.9 LTS we offer two alternative options: the commercial-only Qt Quick Compiler and a new tool to populate the cache ahead-of-time, which is available for both open-source and commercial users. The performance and reduced startup time are in practice the same with both approaches in Qt 5.9 LTS.

When comparing the startup time for the same Qt Quick application with Qt 5.6 LTS without the Qt Quick Compiler to the startup time of Qt 5.9 LTS using the Qt Quick Compiler (or populated cache), the improvement is a whopping 60% on NXP i.MX6. When using the commercial-only Qt Quick Compiler of Qt 5.6 LTS the improvement in startup time is 54% (compared to Qt 5.6 LTS without the Qt Quick Compiler in use). Comparing the startup times of Qt 5.6 LTS and Qt 5.9 LTS when both are using the Qt Quick Compiler the improvement is 14% on NXP i.MX6.

The application used for the tests was the Qt Quick Controls 1 gallery and the tests were run with Linux on NXP i.MX6 and NVIDIA Tegra X1. We used the Controls 1 example because they are much heavier than Controls 2, thus better resembling a typical real-life Qt Quick application. For more measurements of Qt Quick application startup times, please check out the earlier blog post. For instructions to further optimize startup time of a Qt Quick application, please read the second post of our earlier fastboot blog series.

Qt Quick Controls Performance 

Qt 5.6 LTS features Qt Quick Controls 1 while Qt 5.9 LTS features the Qt Quick Controls 2 fully supported. The main design principle of Qt Quick Controls 2 has been performance, as can be seen already from the blog post announcing them. From the very beginning, the key focus area of the new Qt Quick Controls 2 has been for embedded devices and systems. However, these can equally well be used on all supported platforms. Compared to Qt Widgets or Qt Quick Controls 1, the key difference of Qt Quick Controls 2 is that they do not adapt to platform style. We do offer multiple different styles for Qt Quick Controls 2 and it is easy to make your own style as well. From an architectural viewpoint, the key difference of Qt Quick Controls 2 is that they leverage C++ for everything that can be done with C++ and offer just the QML API for applications to use.

As illustrated in the graph above, the performance improvement is huge (note: the higher the bar, the better the performance is). We used NXP i.MX6 running Linux for the measurements. For some of the controls the performance is 14x better than before, and on average the performance has been improved 6x comparing Qt 5.9 LTS with Qt Quick Controls 2 to Qt 5.6 LTS with Qt Quick Controls 1. To benefit from the improved performance, the application needs to be ported to use Qt Quick Controls 2. This is typically quite straightforward and Qt Quick Controls 2 offers most of the common controls. Before porting, please check the documentation, as some controls, such as TableView, are not currently available with Qt Quick Controls 2.

Shader Cache 

Qt 5.9 LTS introduces a new feature to cache OpenGL shaders to disk after the first run, as explained in the blog post introducing the shader cache. If your Qt Quick application is using OpenGL shaders, which is quite often the case, it will achieve a significant improvement in startup time compared to earlier versions of Qt. When comparing the performance of Qt 5.6 LTS to Qt 5.9 LTS using the same Qt Quick application with 10 shaders, we can see a significant improvement in the initialization time of the shaders. Some of the performance improvement observed in the measurement is due to the overall improvements in the graphics performance, but most of the improvement can be attributed to the new shader cache feature.

Qt 5.9 LTS is a whopping 7x faster than Qt 5.6 LTS on startup with the same exact Qt Quick application running the same hardware. Just like the previous measurements described in the blog post, this test has also been conducted using NXP i.MX6 running Linux. The performance improvement is dependent on the hardware and especially the GPU plays a major role. Based on our measurements there are significant improvements with every piece of hardware we have tested – including ones that implement cache feature already in the OpenGL driver.

Memory Footprint Improvements

In Qt 5.8 we introduced a new configuration system and made other improvements to reduce the binary size of the Qt framework libraries used for different applications. This was developed as part of the Qt Lite project, which focused specifically on reducing the application size. With Qt 5.9 LTS we have further polished and tuned the available configurations so that more and more different kinds of applications can reach their minimal Qt configuration. Reducing the size of a Qt 5.6 LTS application is possible mainly by just using the modules needed by the application and statically linking the binary. Because of dependencies within the Qt framework, the linker is not able to reach as small binary size as it is possible with Qt 5.9 LTS using the new configuration tool.

We used a simple, but non-trivial, Qt Quick application (samegame) to compare the needed binary size of the application itself as well as all the Qt libraries it needs. With Qt 5.6 LTS the application requires 24,5MB when linking dynamically. Using static linking, the size is reduced to 13,8MB (still using Qt 5.6 LTS). Leveraging the new configuration tool in Qt 5.9 LTS and with other Qt Lite improvements, the exact same application only needs 5,4MB when static linking is used. Percentage-wise, the Qt 5.9 LTS binary size of the application is 61% smaller than the same application with Qt 5.6 LTS and static linking – without losing any functionality or making any changes to the application.

Improvement in JavaScript Performance 

With the improvements in the QML engine in Qt 5.9 LTS the performance of JavaScript execution has also improved. If the Qt Quick application leverages JavaScript, there is a huge improvement in performance compared to Qt 5.6 LTS, especially on 64-bit ARM. One example of heavily leveraging JavaScript is using three.js on top of Canvas 3D, and smaller amounts of JavaScript are often used in Qt Quick applications.

The measurements are done with v8-bench, which can be found in the qtdeclarative repository. Additional measurements are available at testresults.qt.io. With the v8-bench performance benchmark results of Qt 5.6 LTS compared to Qt 5.9 LTS, the improvement on 32-bit ARM is 16%, but on 64-bit ARM the improvement is a whopping 302% (i.e. 4x improvement). The reasons for the huge improvements are that Qt 5.9 LTS fully supports 64-bit ARM processors combined with the improvements in the QML engine.

Overall Qt Quick Performance Improvements 

The examples above are just some of the highlights from many improvements we have done to the performance of Qt Quick in Qt 5.9 LTS. We have tuned multiple individual areas and optimized the execution paths within the Qt framework. It is important to note that we have also worked hard not to regress in any areas. To avoid regressions, we are regularly running a comprehensive Qt Quick benchmark suite called Qmlbench. With the Qmlbench tool we can see the performance of the most commonly used Qt Quick functionality as well as the functionality that is used less frequently. For more details, please review the thorough explanation of how we are using Qmlbench to avoid regressions.

When comparing Qt 5.6 LTS and Qt 5.9 LTS in the same environment with the comprehensive Qmlbench measurements, we can see  that some areas improved up to 130% as shown in the graph above. Especially layout and complex text performance has improved drastically. The average improvement of Qt 5.9 LTS compared to Qt 5.6 LTS in all Qmlbench tests is 14% (measured on Linux). Despite which functionality is used, the improvement in performance of a Qt Quick application running Qt 5.9 LTS compared to Qt 5.6 LTS is clear and tangible for most applications.

Conclusions

In this blog post, I summarized some of the multiple performance improvements available with Qt 5.9 LTS. Compared to Qt 5.6 LTS, the performance of the same application running on Qt 5.9 LTS is significantly higher. Without making any changes to the application, except for compiling it for the new Qt 5.9 LTS, the performance is significantly improved. Ranging from improved application startup time and smaller footprint through to increased graphics performance, Qt 5.9 LTS is a major step forward performance-wise. Taking some of the new features, such as Qt Quick Controls 2, into use even furthers the performance improvements available with Qt 5.9 LTS.

Interested in taking a closer look? Qt 5.9.0 has been released today. You can get it with your online installer, from the Qt Account or from the Qt Downloads page (for open-source users).

For more details of Qt 5.9 LTS, please check the Qt 5.9 LTS release blog post.

The post Performance Improvements with Qt 5.9 LTS appeared first on Qt Blog.

I’m happy to let you all know that Qt 5.9.0 has just been released. A lot of work has been put into it, making Qt 5.9 the best Qt version we have developed so far.

With Qt 5.9, we have had a strong focus on performance and stability. We’ve fixed a large number of bugs all across Qt, and we have done a lot of work to improve our continuous integration system. This will make it a lot easier for us to create new releases (both patch level and minor releases) from 5.9 onward.

We’ve also added automated performance regression testing to our testing infrastructure, something that will allow us to continuously monitor our work on improving the performance of Qt. Please have a look at the separate blog post for more details.

The new configuration system used in Qt Lite has received many bug fixes, also here, you can find more detailed information in a separate blog post.

Long term supported

One major decision we have taken is to make Qt 5.9 another long-term supported (LTS) release. The previous LTS release, Qt 5.6, is starting to show it’s age, and many users have been asking for a more up to date version of Qt that they can use as a basis for long running projects.

Some of the major changes since Qt 5.6 include more than 2000 bug fixes all over Qt. Additionally, we are now using a C++11 compliant compiler with Qt which has allowed us to modernize our code base. We have also added the Qt Lite configuration system and made significant updates to our graphics architecture. This is in addition to all the other new things that have been implemented in Qt 5.9, explained in the following sections.

As an LTS release, Qt 5.9 will be supported for the next three years to come.

With our improvements on the CI and releasing infrastructure, we are convinced that we will be able to provide you with much more frequent updates and patch level releases for Qt 5.9 than we are able to do for the Qt 5.6 series. As a long term supported release, we will provide you with frequent updates in the first year. After the first year, we will gradually get more and more strict on the changes that will happen in the branch, so as a result, patch level releases are expected to happen somewhat less frequently for the second and third year.

We will as promised also continue to support Qt 5.6, but we strongly recommend everyone starting new projects to use Qt 5.9 as there are a lot of improvements across the board that will be of huge advantage to you.

Lots of new functionality

Even with our focus on performance and stability, we have managed to add more new features into Qt 5.9 than I can mention in this blog. For a more complete list have a look at the ‘New Features’ page in our wiki.

Here are some of the highlighted new features.

Core and Networking

Quite a few new features have been added in the Core and Networking modules. Starting at the base, Qt Core has two new classes. The first class, qfloat16 abstracts 16-bit floating point numbers, as these nowadays are increasingly more important for inter-operation with APIs which make use of the GPU. In addition, a new QOperatingSystemVersion class has been added to conveniently test for the operating system and version your application is running on.

Qt Network has gained support for HSTS (HTTP Strict Transport Security), improving security on HTTPS connections through QNetworkAccessManager.

Our NFC support in Qt NFC has seen some very nice improvements for Android, and Qt Web Sockets can now use external TCP sockets. Classic Bluetooth on WinRT and Bluetooth peripherals on Android are now both supported.

Qt Gui and 3D

Qt GUI has gained a shader cache, that can cache compiled versions of OpenGL shader programs, and we have added support for Compute Shaders. The OpenGL paint engine does now work with OpenGL Core profiles as well.

An enormous amount of work has been done with Qt 3D. Together with the functionality we already had in Qt 5.8, we now have a fantastic 3D engine in Qt 5.9. You can find all the details in a separate blog post by our partner KDAB.

Qt QML and Quick

Quite a bit of work has been put into improving the QML and JS engine for Qt 5.9. We have added a completely rewritten garbage collector, offering better performance and reducing memory fragmentation in the JavaScript heap. The new collector also provides a better basis for further enhancements to our memory management in upcoming Qt versions.

Qt 5.9 also comes with a brand new QML caching infrastructure, offering similar benefits to our users — just like the commercially available Qt Quick Compiler, but in a much more transparent way. The new infrastructure has two modes of operation. In the default mode, the caching infrastructure creates a binary cache of your QML files at the first start-up of the application. Optionally, you can also pre-create that cache at application build time, achieving similar performance and startup time benefits as with the Qt Quick Compiler. Additionally, the new caching infrastructure does not bind your application to a specific patch level version of Qt, as the binary caches are versioned and will get regenerated if required.

Also, a lot of work to improve performance and reduce memory consumption has been done in the engine, making this a significant upgrade compared to our previous Qt 5.6 LTS release.

Qt Quick now makes use of the new OpenGL shader cache added in Qt GUI, improving application startup times. We added an image provider that can share image data between processes, and a new OpenVG backend, allowing it to run on hardware that only has 2D hardware acceleration support.

Qt Quick Controls 2 has added more new features than I can mention here, please have a look at the separate summary blog post, which links to all the details and blog posts on what has been added in Qt Quick Controls since Qt 5.7.

Qt Location and Positioning

For this release, Qt Location has received quite a few new features. We’ve added support for tilting and rotating maps, both through the APIs and through touch gestures. Stacking of maps has been improved, it’s now a lot easier to add overlay items to maps, and we improved the support for blending in copyright notices on the maps.

An entirely new plugin adds support for Mapbox, using their OpenGL based map rendering engine.

A couple of other visual improvements have also happened, like using lower resolution tiles to approximate tiles that are still missing at a higher zoom level until those are downloaded.

On iOS, we improved Qt Positioning, so that it now can collect data even when the application is in the background.

Other modules

Many other modules have also been updated. Most notably, Qt Webengine is now using Chromium 56. Qt Virtual Keyboard now supports external keyboard layouts and many other cool new features.

Qt Gamepad has graduated from Tech Preview status to being fully supported in Qt 5.9. We’ve also added Qt Remote Objects as a new module in Technology Preview status.

There have been significant changes to Qt Wayland that are described in a separate blog post.

Of course, Qt 5.9 also comes with a brand new version of Qt Creator with many great new features. The Qt Quick Designer now contains a built-in code editor, and we now have a completely rewritten the cmake integration. For further details, have a look at the separate blog.

Platform changes

Qt 5.9 adds support for two new platforms. It now supports QNX 7.0, the latest version of the QNX operating system. We have also added support for the INTEGRITY OS, details about this are again in a separate blog post.

Finally, we added support for compiling Qt in a size optimized mode (-Os on GCC), saving around 5-20% in binary size for the Qt libraries and your applications.

Thanks

Finally, I’d like to thank all the people who have contributed to this release. While you can see and follow all the people contributing code through patches to our git repositories, a lot of additional work has happened more invisibly behind the scenes, for example by working on our CI and releasing infrastructure or helping to create collateral and content for the web pages.

I hope you’ll all enjoy this release. You can get it from the usual places, either through your Qt Account or from our download page. Please also don’t forget to give us your feedback, and write a bug report (if you should find one), so that we can improve the 5.9 series even further in upcoming patch releases.

The post Qt 5.9 released appeared first on Qt Blog.

Qt 5.9 has just been released!

This release marks two important milestones for the Qt Project. The first is that now the Qt 5 series has had more releases than any other Qt version ever (the last release of the Qt 4 series was Qt 4.8). The second milestone is that Qt 5.9 will be a Long Term Support release, therefore providing to many users a stable foundation to build their applications upon.

KDAB has been a significant contributor to this release, as shown by the number of commits by KDAB developers merged into Qt. In this blog post I will showcase some of the most outstanding contributions to Qt 5.9 developed by KDAB engineers. continue reading

The post KDAB contributions to Qt 5.9 appeared first on KDAB.

This time I’ll cover the topics performance as well as upcoming hardware and software changes.

Performance

You have all noticed that the CI system is behaving poorly to what comes to the performance. Sometimes autotests take over 30 times longer to run compared to a normal situation. Now why is that?

We actually have different kinds of bottlenecks. One is the bandwidth with which the virtual machines (VMs) store local data to their virtual hard drives. The servers on which our virtual machines run have no local hard drives. They instead store all their data on a centralized storage called the Compellent (https://en.wikipedia.org/wiki/Dell_Compellent). So when a VM wants to store data on its virtual hard drive, the host it runs on actually stores the data on the centralized storage.

We have several generations of hardware installed, and they have different speeds on their SAN interface with which they are connected to the Compellent. As your build picks up a server, it can be a new rack server, or it can be an older generation Blade (https://en.wikipedia.org/wiki/Blade_server). Also, all the other VMs on these servers share the same bandwidth, so depending on what the other builds do, your SAN connection can be affected. Sadly, our test of prioritization these VMs, didn’t produce expected results and really didn’t much at all.

These generations of hardware and type of hardware also affect the amount of other VMs the hardware can run simultaneously.  We have Mac mini’s running our macOS builds. Those generally run 1 VM per physical Mac mini. Then we have old Blades that run around 4 VMs per Blade. The latest additions to our hardware pool are dual socket 20 core CPU server racks. Those run up to 26 VMs simultaneously. Running more on the same hardware reduces costs for us, but also increases the odds of one build affecting the next.

Another bottleneck is the Compellent itself. The storage system has 120 + 10 spare hard drives spinning at 15K RPM. However great the IOPS performance is in that system, when we decide to start 200+ VMs in the CI, it goes down to its knees. And when it does that, all builds and autotest run are affected. You could think of this as you having 2 computers at home sharing the same spinning disk.

Now that all is grim and morbid, let’s continue with the good news.

Upcoming hardware changes

We’re replacing the current hardware stack with a completely new one. The parts have arrived and are being installed as I type right now. Not only did we acquire new hardware that is faster, but we also redesigned the building concepts so that they utilize the hardware differently. The new hardware can be easily expanded and we designed the system so, that we don’t produce bottlenecks even when expanding it.

Before I go in to details, I need to explain a bit how the CI systems generally works. So, heading off on a tangent here! When developer stages a commit in Gerrit (codereview.qt-project.org), the CI picks it (or multiple commits) up. The CI or Coin as the piece of software is figuratively called, generates work items based on the data received. If let’s say the commits was for QtDeclarative, Coin now produces work items for itself to handle that QtDeclarative build on top of circa 30 different target platforms. Each of these work items depend on QtBase to be built. So now Coin also creates these circa 30 work items for QtBase. As QtDeclarative is built on top of the current qt5.git’s QtBase, it means in normal situations that QtBase has already been built previously. These artifacts have been stored by Coin and can now be reused. So instead of rebuilding QtBase for QtDeclarative, Coin simply checks its storage and links the previous builds to the current one and promptly continues with building QtDeclarative. This is the major change in how we build Qt nowadays compared to old days with Jenkins where every build always rebuilt the entire stack up to its point. You may read more about it in this blog post.

Continuing into more details. Whenever Coin starts to build something, it needs a VM for the task. We have “templates” in vSphere that represent different operating systems. They are virtual machines that have operating systems installed in them along with some basic things set up like user accounts and SSHD etc. Then they have been shut down ready to be used. Now when a build needs a VM, it clones a template VM and launches the clone. The clone is actually only a linked clone. This means that we don’t really clone anything, but only create a new virtual machine that links or points to the original one. Now, when the new clone is powered on, it _reads_ from the original template, but all changes are _written_ to its own file called the ‘delta image’. This way a new virtual machine only takes up space that’s equal to the amount of data it has written.

Going back to the template again. I said that it only contained basic things like user accounts and SSHD. A build surely needs more than that. We need Visual Studios, MINGW, CMake, OpenSSH, XCodes, MySQL etc. installed as well. Those things are ‘provisioned’. In qt5.git we have a folder structure under /coin/provisioning that contains scripts that install these things. As there is no point in running them every time for every VM, we create yet another set of templates that contain these pre-installed. We call these TIER2 images (or templates) vs TIER1 images being the vanilla distros containing only the basic things enabling us to even use them.

TIER2 images work pretty much the same way as QtBase was a dependency for QtDeclarative. Each build we trigger checks the current configurations scripts from qt5.git and makes a SHA from the folder structure. This SHA is used in naming the TIER2 image. If the content we want to install has changed, we have to regenerate a new TIER2 image. This is called the provisioning and it’s triggered automatically if the requested TIER2 image doesn’t exist.

Now, let’s go back on track and talk about the hardware changes.

The new servers have local SSD drives that work as the storage for the VMs instead of a centralized storage. This removes the bottleneck of a SAN network and reduces latencies while at it. And while being SSD drives, they are faster by design to what the Compellent used to be with its rotating discs. We still have a Compellent, but this time it’s filled with SSD drives. While the VMs use local SSD drives on the hosts themselves to store data, reading is a more complicated thing.

The TIER1 and TIER2 images described earlier are still stored centralized on the Compellent. This saves us the transferring of the images to each server serving as the host for the VMs. These TIER2 images are cloned as normal, and then the read operations point to the source. This would cause the same situation as with the old system where everything is read from the Compellent, but we are relying on caches to work in our favor here. The TIER2 images are shared via NFS, and the host OS on the server is equipped with a 500 GB NFS cache. So, whenever something is read from the TIER2, it is in fact now read from the NFS cache that’s local. All this is obviously assuming that the data has been read once previously. In practice, if a TIER2 image gets updated, the data has to be read from the centralized storage once, and then it’s in cache for the rest of the builds. We also have to remember that not the entire TIER2 image is read whenever data is read. If a build requests openssh.so, only those blocks containing the file are read.

We also need the Compellent to provide us with redundancy for critical systems and a huge data storage for data that can’t be stored distributed. Critical systems include our own infrastructure and the storage is needed for all kinds of data including our release packages, install packages, distro ISO images etc. So even if we had a good mechanism to distribute the entire TIER1 and TIER2 load to the servers themselves, currently there is no need for it and the Compellent serves this need more than well right now.

The new hardware infrastructure will include new switches and firewalls as well. And all these are being set up in new premises, so everything is new. With this we will expect a few maintenance breaks during the upcoming months where services are being handed over from one site to the other. The down times should be relatively low, since all data is being transferred beforehand and not during the down times.

Software changes

Currently Coin is using VMware’s vSphere technology to create and run VMs. That’s about to change. Our new spinal cord will be based on OpenNebula (https://opennebula.org/). The swap to this new technology will come at the same time we switch to the new facility with the new hardware. We’ve been working hard to get the robustness and reliability up, matching or even exceeding the one provided by VMware’s products. With open source non-proprietary code we can go deep into the root causes of problems and fix drivers if that’s needed to make our VMs run smoothly without hick-ups. With OpenNebula being KVM based, we can expect new distro support to be available sooner as well. No longer do we need to fall back to saying a new macOS can’t be installed because VMware doesn’t support it. Let’s hope I can hold up to this promise or claim 😉

Performance wise the comparison between VMware and OpenNebula is a bit unfair since they use different underlying hardware, but we can say that builds aren’t going to get any slower by the looks of it.

We’re also working on getting all of our distros more provision scripted. This will make it a lot easier for anyone ( yes, this includes you ) to upgrade the software that’s being run on the VMs. Anyone can access qt5.git/coin/provisioning and modify / add scripts there. Normal code review procedures apply and TIER2 images get updated.

Internally we’ve had 3 different Jenkins instances in the past. We had one for CI that got replaced by Coin a year ago. The remaining two were for release package creation, Creator builds and few others, and the second one was for RTA standing for Release Test Automation where we verified the packages to really install something and examples working etc. Those two Jenkins instances are planned to be merged with Coin at some point in time, but for the time being they are going to stay there for a while. However, we’re improving the backend of how they receive their VMs. They currently compete with Coin in getting hardware resources. In the next weeks, this is going to be changed so that Coin creates these VMs. This takes away the race conditions between two back ends, but also gives our Jenkins instances “support” for OpenNebula VMs. Even if this does not show up directly to you as CI users, it should show up with slightly more reliable VM dedication, more effective cleanup of VMs, and at least from the technical perspective we should be more capable of producing packages faster.

The post CI Performance, HW and SW changes appeared first on Qt Blog.

As you all probably know already, the crowdfunding for qutebrowser ended up being more than fully funded - thanks to everyone again!

The funds arrived on my bank account yesterday, minus some 10% fees for Kickstarter and payment processing. Yesterday also was the last day with lectures before my summer holidays!

Since Monday is a public holiday, I decided to spend some time today on sending out the stickers to everyone who doesn't have a t-shirt, and then continue next Tuesday with day 2.

Over the last few days, I also spent some time on getting QtWebEngine more ready:

• New private browsing which supports QtWebEngine
• Windows binaries now are built with QtWebEngine
• Using legacy QtWebKit now displays a warning
• Using QtWebEngine with Nouveau shows an error instead of crashing

For people who have t-shirts in their pledges, a survey will follow soon - I still need to sort out some things about available colors and sizes first.

If you're reading this via the Python or Qt planet, note that I won't post future minor updates there - if you want updates about what I'm doing currently (a few times per week), check the qutebrowser development blog!

So ya, I have been doing work for the up and coming Finnish company Intopalo getting Qt5 for WebAssembly using emscripten up and running. This is the 3rd Finnish company I have done work for, and the 4th Nordic company (Trolltech, Nokia, Jolla, Intopalo)

This is very much a work in progress.

Background:

There was a Qt4 version, emscripten-qt and a related Qt5 for Native Client which do similar things, and we have taken inspiration from both these projects. Thanks!

The gist of it:

We use emscripten to cross compile Qt5 into javascript and/or webassembly. We use 'incoming' from emscripten's git repo. Details how to build emsdk are here.

My working Qt5 repo is here, (the wm branch contains multi window and window decorations) while there is also an outdated WIP gerrit MR  which will get updated at some point.

This is how I configure Qt for emscripten:
 . ~/emsdk/emsdk_env.sh (to get em compiler in path)

~/depot/qt/qt5/qtbase/configure -xplatform emscripten -confirm-license -opensource -nomake tests  -nomake examples -developer-build -no-dbus -no-thread

 (no-thread is a new feature I added for this, as threading in javascript is basically non existent)

and then, use that qmake to compile a Qt app!

To run the app, in the firefox browser
emrun --browser firefox path/to/app.html

This is all bleeding edge from the emscripten compiler to the web assembly support in the browser, so your mileage may vary.

With the 'wm' branch of my github repo, multi windows and window decorations are kind of working. As well as compiling into webassembly and not just javascript asmjs.
Compiling into wasm brings much smaller download sizes, but you need to have a browser that supports it.

There is still heaps of work to do to bring it up to release state. So for now, it is still a research and WIP project, and a lot of things may or may not work. But it can run some Qt widget based apps in your (firefox) browser!

As some of you may have heard, one of the new features in Qt 5.10 is the introduction of a set of basic Vulkan enablers. Now that Qt 5.9 is out, it is time to take a look at what this covers (and does not cover) in practice. In order to keep things fun and easy to read, this is going to be split into a series of shorter posts. It must also be mentioned that while the new features mentioned here are all merged to the dev branch of qtbase, there is no guarantee they will not change until the release of Qt 5.10.

Motivation

Qt 5.8 started the research and implementation for gradual improvements when it comes to supporting graphics APIs other than OpenGL. There the focus was mainly on Qt Quick, and scenegraph backends that either do not involve new platform specifics (software) or are available on a single platform/windowing system only (Direct3D 12).

As shown in the pre-work for our D3D12 experiment, getting started with such APIs is easy: 1. grab the native window handle (for example, in case of Windows, QWindow::winId() is the HWND); 2. add your platform-specific code to render stuff; 3. done!

Now, the same is of course possible with Vulkan, as proven by the various projects on GitHub and elsewhere. So what is the point in touching QtGui, the QPA interfaces, and the platform plugins?

Well, things become more interesting when multiple platforms come into play: the way windowing system integration is done in Vulkan requires writing platform-specific code, likely leading to a bunch of ifdefs or similar in cross-platform applications.

Given that we have a cross-platform framework (Qt), it is fairly natural to expect that it should help with abstracting and hiding these bits.

So instead of this:

QWindow *window;

#if defined(VK_USE_PLATFORM_WIN32_KHR)
    VkWin32SurfaceCreateInfoKHR createInfo;
    createInfo.hwnd = (HWND) window->winId();
    ...
    err = vkCreateWin32SurfaceKHR(...);
#elif defined(VK_USE_PLATFORM_WAYLAND_KHR)
    VkWaylandSurfaceCreateInfoKHR createInfo;
    ...
    err = vkCreateWaylandSurfaceKHR(...);
#elif defined(VK_USE_PLATFORM_ANDROID_KHR)
    VkAndroidSurfaceCreateInfoKHR createInfo;
    ...
    err = vkCreateAndroidSurfaceKHR(...)
#elif defined(VK_USE_PLATFORM_XCB_KHR)
    VkXcbSurfaceCreateInfoKHR createInfo;
    ...
    err = vkCreateXcbSurfaceKHR(...)
#elif ...

why not have something like the following:

QWindow *window;

VkSurfaceKHR surface = QVulkanInstance::surfaceForWindow(window);

The windowing system specifics are now conveniently handled in Qt’s platform plugins. No more ifdefs.

The second important motivation factor is that even the D3D12 experiment has shown that many applications are happier with a higher level convenience window class, like QD3D12Window, following the example of QOpenGLWindow. These are inherently limited in some ways, but avoid the need for doing everything from scratch with QWindow (and juggling with surfaces like in the above example…).

Using QWindow directly remains the most powerful way always, giving full control to the application, but as we will see later, doing a fully featured and stable Vulkan-based QWindow is not exactly trivial (think swapchains, exposeEvent(), resizing, QPlatformSurfaceEvent, etc.). Hence the introduction of QVulkanWindow.

What This Is Not

Before moving on to the new QVulkan* classes in detail, let’s clarify quickly what the Vulkan support in Qt 5.10 really is:

• Qt 5.10 enables applications to perform cross-platform Vulkan rendering in a QWindow and the convenience subclass QVulkanWindow.
• Besides abstracting the windowing system specifics, a thin wrapper is provided for Vulkan instances and the instance and device specific functions of the core Vulkan 1.0 API.
• The Vulkan API is not abstracted or hidden in any way. Qt does what it should, i.e. helping with windowing, platform specifics, and function resolving for the core API, but no more than that.
• Vulkan-based QWindows can be combined with QWidget-based UIs using QWidget::createWindowContainer(). They are no different from OpenGL-based windows in this respect. This is excellent news for 3D tooling type of applications on the desktop using QWidgets, since there is now a Vulkan-based alternative to QGLWidget/QWindow/QOpenGLWindow.
• Vulkan support does not currently cover modules like Qt Quick, Qt 3D, Qt Canvas 3D, the OpenGL backend of QPainter, the GL composition-based QOpenGLWidget/QQuickWidget, etc.
• Vulkan support may be introduced to some of these in the future, however this is not in scope for Qt 5.10.

Platforms

So what platforms are supported?

As of Qt 5.10, the situation is the following:

• Windows (desktop, not WinRT): when the LunarG SDK is installed, and thus the VULKAN_SDK environment variable is set, Vulkan support will automatically get enabled in the Qt build.
• Linux (xcb only at the moment; support in the wayland platform plugin to be added later on): enabled whenever the Vulkan headers are found during configure time.
• Android (tested on API level 23 and 24; note that the Vulkan headers (and related tools) are only present in level 24 and newer NDKs out of the box)

Note that Qt’s Vulkan support does not rely on linking to a Vulkan (or loader) library, and rather relies on resolving everything at runtime. Therefore the only hard requirement is the presence of a relatively recent set of Vulkan headers (like > 1.0.13 or so).

When it comes to the pre-built packages, we currently have some open tasks to investigate and implement support for Vulkan-enabled builds on some platforms at least. Hopefully this gets sorted out in time for Qt 5.10.

That’s it for part 1. Stay tuned for part 2, where we will start digging into the actual QVulkan classes!

The post Vulkan Support in Qt 5.10 – Part 1 appeared first on Qt Blog.

The Qt Company support team works hand-in-hand with Qt R&D developers and we are 100% committed to ensuring that you succeed with your project.

We have recently launched new support services and in this blog post I would like to introduce you to the new offering and in addition give you an introduction to the Qt Support team. The new support offering has been modified and we have launched two different levels of support, which have been named ‘Standard’ and ‘Premium’ Support. In addition to our standard offering, all 5.x releases can be extended with Extended Support.

The Team

We have a team of experienced software engineers working in Qt Support. All of us have a long background in software development and with Qt. Currently we are working from three different locations, Oulu, Oslo and Santa Clara and we are considering expanding our locations to Tokyo, Berlin and Boston during this year.
With new locations covering multiple time zones, we will be able to give even quicker responses to our Asian and US based customers.
The Qt Support team is part of Qt R&D and we work closely with the development teams. Being closely connected with where the development happens means that we are always up to date with the latest new features and we know the best practices on how to leverage these new features. For you as a Qt user, it also means that if you have an issue, we know who to contact and we can solve your challenges quickly.

Standard and Premium Support

Earlier we had three different support levels, but now we have reduced those to two and changed the names of two levels moving forwards. The previously known Silver Support will now be called ‘Standard Support’. The SLA terms are still the same as earlier with Silver Support. The new Support plan name, Standard Support, will be visible to you in your Qt Account.
Gold support has been renamed to Premium Support. Current Gold support customers will continue to get their service under the old Gold Support SLA.
The entry level support, Bronze Support has been phased out.

All Qt customers with an active license (except for start-up licensees) are entitled to Qt Support. Standard Support is bundled with all new Qt licenses. It comes with a two business day response time guaranteed and provides you priority to the customer reported Qt errors.
If a more personal and quicker support service is required, the Premium Support is the way to go. With Premium Support, we offer a dedicated support person and the possibility to utilize online chat through remote desktop connection. With Premium Support, our target is to respond within the same workday as the issue is reported. Also, reported bugs and other issues are treated with even higher priority than with Standard Support. With Premium Support, we also analyze the complete customer application code base and debug that instead of requiring a minimal test application where the issue is reproduced.

Support Level Details

*Within reasonable efforts, not every bug is fixable as part of Qt Support

Extended Support

Qt 5.4 and later releases are currently supported by default. If support is required for older and unsupported Qt 5.x releases the support can be separately purchased as Extended Support. This will allow the customer to ask questions and report issues occurring on these older Qt versions – in the same way as if the phased out Qt version was still officially supported.
By default, releases from Qt 5.6 and onward are supported for one year and LTS releases are supported for three years starting from the 5.x.0 release.

Support periods for Qt 5.x releases

More information regarding the different support levels can be found on the Qt Support pages.
Both Extended Support and Premium Support upgrades are targeted for complete development teams.

The Help We Provide

In most cases, Support provides a fix or a workaround for the reported issue. The remaining issues are then followed up by our development teams. Qt Support flags these bugs as being originating from commercial customer and thus gets higher priority when R&D prioritizes bugs to be fixed. Therefore, it is important that all the bugs that the commercial Qt customers encounter are also reported to the Qt Support team.

Even though helping customers tackle Qt bugs is a prominent function of the support team, we also do a lot more. Most questions sent to Support are actually not related to bugs, but rather related to finding optimal coding solutions for the problems customers are facing in their code. We have also been compiling a Qt Support FAQ page, which deals with the most common issues. The Qt Support FAQ is accessible through your Qt Account.

We have been measuring Qt support customer satisfaction for many years now and we have always had a high rating. 9/10 customers have been satisfied or very satisfied with our service. Our main target is to keep our customers happy and productive with Qt. The future of our framework relies on successful projects and therefore we put a lot of effort into providing the best support possible.

You can find more information about Qt Support on the support pages or via Qt Account and we are also more than happy to provide you with a quote. Please do contact us if you have any questions regarding our offering.

The post Renewed Qt Support Services appeared first on Qt Blog.

Qt is putting the pedal to metal within the automotive industry with our Qt Automotive Suite offering and we have a lot of interesting automotive related #BuiltwithQt cases, videos and demos. We are attending TU Automotive in Detroit this week, where both our partners and The Qt Company will have booths displaying the latest and greatest within automotive.

We had so many automotive showcases at Embedded World 2017, from both our partners and The Qt Company, and in this blog you will find some of the selected ones. It is really cool to see how this industry is driving technology forwards with innovation. There is a good chance you’ll see some of these demos at the TU Automotive event as well.

Multi-screen demo on single SoC with Integrity RTOS

As the pressure on proving a unified UX across all screens within automotive is rising, there is also a pressure to keep costs down. QML can save you up to 40% off the hardware cost and really allows you to squeeze the juice out of your hardware. In the following video you can see our multi-screen demo, running on a single SoC using Integrity RTOS and the application manager in the Qt Automotive Suite, based on the Wayland Compositor, for managing the complex architecture.

Gesture Controlled Infotainment

Like straight out of Minority Reports, gesture control is on the horizon – who likes talking to your car anyways when you can make hand gestures to control the temperature of your car? The future is interesting. Check out the gesture controlled IVI using Qt Automotive Suite with our partner, brightONE:

All-in-One Carputer

Our partner, LinkMotion has developed something they call a Carputer, it’s a nifty name for an all-in-one solution consisting of hardware and the Qt Automotive Suite supporting. Oh, and the Carputer is used by a car manufacturer that creates super-fast cars. Some might know them as the raging bull of the automotive industry. Check out LinkMotion’s demo of their Carputer:

Worlds Fastest Electric SuperCar

Not only is the raging bull of automotive using Qt, but our friends over at Rimac Automobili have created the world’s fastest electric supercar with a Qt based IVI and digital instrument cluster. The world’s fastest electric supercar deserves the world’s fastest software and there is no wonder why they choose Qt. I could also name some other fast electric mass produced cars who have their in-vehicle screens built with Qt (they might be from Californi-a), but I’ll save that for later. As Damir from Rimac so nicely states: “The Rimac Concept_One is limited to 355 km/h or 220 mph”­– I wonder how fast it can go without the limitation. And how fast will cars go when they are all autonomous? The roads will be far safer. Will there even be speed limits?

TU Automotive

We are going to be at TU Automotive in Detroit this week. Do come and see us and talk with us about what we can do for your automotive program. Here are some of the featured partner demos at TU Automotive which are built with Qt!

• Harman | HCAT HMI Solution & Echo Cancelations and Noise Reduction software 
• Green Hills | Automotive Instrument Cluster HMI built with Qt on INTEGRITY 
• QNX | QNX Hypervisor, instrument cluster and infotainment built with Qt and featuring Qt, HTML and GL 
• Mapbox | Qt Automotive Suite running on Intel NUC featuring Mapbox Vector Map integration

At the Qt booth we will be showing:

Multiple Display Synchronization with a Single Processor

Streamline reference UI/UX designs for IVI systems including multiple IVI applications and application store development

• Independent App process per app enables modern updating functionality
• Display on multiple screens
• Qt Wayland Compositor for display composition
• Embedded Linux running on Intel NUC
• Qt Automotive Suite

Qt Fast Boot Instrument Cluster  

Boot up your project in 1.2 seconds with Qt (Qt applications are not the limiting factor – the OS and hardware is)

• Toradex Apalis NXP i.MX6 Quad core processor, 1GHz
• 1GB DDR3 RAM, 4GB eMMC
• 1280 x 480 Display
• Embedded Linux Qt for Device Creation

Check out the Toradex Apalis i.MX6 going head to head with the NXP Sabre i.MX6 to achieve the fastest boot time on a digital instrument cluster:

Qt 3D Studio for Future Automotive Instrument Cluster UX/UI

Qt 3D Studio is an authoring tool for rapidly creating interactive 3D interfaces and applications and was the biggest contribution to Qt ever. Thank you, NVIDIA!

• WYSIWYG editor for 3D scenes and animations
• Application deployed on Intel NUC and Google Pixel C
• Built material and effects library
• Mix 2D and 3D user interfaces by integrating Qt Quick
• Combining Qt 3D Studio, Qt Quick Designer, and State Chart Editor

Check out how a 3D HMI is built in less than 30 minutes in the following video:

Qt Automotive Suite gets you first to the finish line whether is in your software development project or in one of the super-fast cars running Qt. If you have questions about creating the digital automotive cockpit of the future, whether it be a cluster with safe rendered components extended with a heads-up display, smack bang in the middle of your windscreen, showing you the way to go in an augmented reality futuristic way or an IVI with a branded look and feel across all screens. And with Qt you can also re-use your code so if you want to put your cockpit in your pocket with our mobile offering and create your companion app for iOS or Android – we’ve got you covered. Qt really does have everything you need for your automotive program. We even create branded SDKs to make sure your teams and third parties are all aligned using the same tools and libraries. Contact us or come talk to us at TU Automotive. Be there or be…well…outdated.

The post Built with Qt: Episode II – Driving the Automotive Industry appeared first on Qt Blog.

As there were some complex issues around conformity in PDF document creation within Qt, KDAB let me spend some time digging into it so we could make sure that Qt’s PDF engine generates documents up to ISO-standard.

Nowadays, many official institutions have the requirement to archive their data digitally and PDF is a first class citizen for this purpose. However,since the overall PDF standard is too complex, to guarantee that PDF documentscan be rendered in their entirety in…

The post Creating PDF/A documents with Qt appeared first on KDAB.

We are pleased to announce that Qt 5.9 will be a Long Term Supported (LTS) release. We have done a lot of improvements to Qt since the previous, Qt 5.6 LTS, and to maximize the benefits for our users we will make Qt 5.9 an LTS release. There will be several Qt 5.9.x patch level releases created during the next three years – also after the next Qt 5.x releases become available. Commercial licensees eligible for technical support will also be able to submit support requests during the whole LTS period.

Since the release of Qt 5.6, our previous LTS release, a huge amount of improvements has been added to Qt. We have done significant work on improving performance, added multiple important new features, and fixed thousands of bugs. Qt 5.9 LTS is a fantastic product that offers substantial improvements over Qt 5.6 LTS. To make it possible for all our users to benefit from these, we will be providing Long Term Support for Qt 5.9.

As with Qt 5.6 LTS, we will be using a phased approach to content in patch level releases for Qt 5.9 LTS. During the first 6 months after release day, an LTS release receives a lot of fixes, including low-priority ones. Then the LTS release enters a ‘strict’ phase where only critical bugs and security issues are addressed. This will ensure the stability of the LTS releases. During the final year of an LTS release the commit policy is ‘very strict’, at which phase we only address severe security issues.

For all new projects, we strongly recommend using Qt 5.9 LTS. The upcoming Qt 5.9 LTS will be supported alongside with the earlier Qt 5.6 LTS release, which still allows the use of the old C++98 compilers. As already noted above, Qt 5.9 LTS offers lots of performance improvements as well as a vast amount of other improvements and bug fixes that are not included into Qt 5.6 LTS. Currently, Qt 5.6 LTS is in the ‘strict’ phase where it only receives selected critical fixes and next it is moving into the ‘very strict’ phase. During this final phase, Qt 5.6 LTS will receive important security fixes only.

According to our LTS promise, we guarantee that Qt 5.9 LTS will be supported for three years via standard support, after which additional extended support can be purchased. During this time, even though following Qt releases (5.10 onwards) are already out, Qt 5.9 LTS will receive patch releases providing bug fixes and security updates. For an LTS release, the amount of patch releases will be higher than non-LTS releases of Qt and we aim to provide these throughout the LTS period. In addition to security fixes, error corrections and improvements provided by the LTS patch releases, we may also add support for new operating system and compiler versions to an LTS release of Qt, when feasible. It should be noted that the deprecated modules and technology preview modules are not subject to the LTS.

Qt 5.9 Beta releases are already available via the online installer, check it out if you have not yet done so. If you do not have the Qt online installer yet, please get it from the Qt Account or the Qt downloads page. We are working hard to further fix and polish it with the target of having the Qt 5.9.0 final out around the end of May 2017.

The post Introducing Long Term Support for Qt 5.9 appeared first on Qt Blog.

Hey,

After some months (years :p) without any special move in MkS I decided to *archive* the website.
Currently it cost me a lot of time to maintain the web part of the MkS project, update drupal, update any of its modules etc.
This is inefficient because to be honest, nothing in this CMS is serving us apart the blog/story/wiki.
So I decided to move to a plain html/js static website which posts, blogs and wiki pages are just requested from xml request from a json file.
i will just have to update this json file to add any new content, very easy to handle / maintain.

read more

With an apology to English-speaking audiences

Anche quest’anno KDAB partecipa a QtDay, la conferenza italiana interamente dedicata a Qt. Giunta oramai alla sua sesta edizione, QtDay continua a crescere. Quest’anno QtDay si articola in 3 giorni: il primo dedicato a un training su QML, seguito da due giorni di conferenza vera e propria.

Durante la conferenza terrò due interventi:

• Venerdì 23 giugno parteciperò ad una tavola rotonda sul come contribuire allo sviluppo di Qt;
• Sabato 24 giugno

The post Ci vediamo a QtDay 2017? appeared first on KDAB.

We have released version 2.8.0 of our Qt application introspection tool GammaRay. GammaRay allows you to observe behavior and data structures of Qt code inside your program live at runtime.

A big focus in this release is improvements to the Qt Quick inspector, which gained layout helper grids and Qt Quick Controls 2 tracing, as well as initial support for the software renderer. We have also optimized the performance of the remote view, which previously managed to saturate a …

The post GammaRay 2.8.0 Release appeared first on KDAB.

Choosing a framework for your next cross-platform app is an important decision. In this post we’ll cover multiple factors to consider when choosing your app development framework and how that should support your business strategy.

What to Consider

Determine the reasons why you may need a cross-platform mobile app:

• Do you want to improve your brand and better position your company in mobile app stores?
• Do you want to make your employees more productive with internal apps that they can use on their tablets or phones?
• Do you want to save the cost of having a dedicated Android and iOS development team and instead have one team that’s able to cover all platforms with a single source code basis?
• Will you have to maintain your app on multiple platforms over a long period of time? Your iOS and Android versions may drift apart in terms of functionality and features because maintaining multiple platforms requires a lot of effort and dedicated experts for iOS and Android. With a cross-platform solution, you can avoid different timelines per platform and reduce maintenance costs.
• Do you need to reduce the amount of duplicate code for multiple platforms such as iOS, Android and Desktop?
• Do you have existing business logic or even a desktop application written in C++ and now want to bring it to mobile?

If you answer yes to just a couple of these questions, you should be considering a cross-platform mobile app strategy.

Let’s dive into the question, what your cross-platform framework should provide:

Animated UIs

Successful apps all have one thing in common: a great user experience and smooth animations that give the user a sense of joy.

So to create a modern mobile app, the user interface and the screen transitions need to be animated. Adding animations and prototyping different UIs should be the core strength of your framework. Take Qt Quick (aka QML) as an example – QML was essentially designed and written with this goal in mind.

If you’ve developed native apps for Android or iOS before, you’ll know that getting these animations right is a major time sink. Using a declarative design approach will save you time and money.  QML allows you to easily animate any user interface element with dozens of different easing types and gives your app that extra level of polish

(Very) Few Lines of Code

Another benefit of QML is its declarative structure: You can define UIs and animations in less than 20 lines of code and they’ll still be easy to understand and read. With advanced features, such as property bindings, you can save even more lines of code. This requires a lot of boilerplate code in other programming languages.

Native Performance

The basis of QML is C++ which has much better performance than any JavaScript-based framework. In addition, the rendering of QML is handled from a modern scene graph optimized for mobile. Thanks to this scene graph and C++ basis, the animations and loading times are on a native level, just like a regular iOS or Android app.

Business App Requirements

Qt supports many requirements in modern business apps. It allows you to access your backend APIs via WebSockets or REST/HTTP, add location and maps services, display HTML 5 content, access sensors, multimedia, databases, localization features, and more connectivity access via Bluetooth LE or NFC.

Compatibility with Your Existing Business Logic

If you have existing business logic in C++, you can include that code and reuse it for your mobile apps. You don’t need to start from scratch and can focus on providing a great UI to users.

Extensibility

If a native feature you need is not covered by Qt yet, you can add it on your own and then provide it to QML with a clean scripting API, from native Java or Objective-C/Swift code to QML. This also allows you to add 3^rd party SDKs, which might only be available for iOS or Android. Some of the most popular mobile services are available in a cross-platform format as V-Play Plugins – see the upcoming part 2 for more details.

Components Designed Specifically for Mobile App Development

Qt with QML fulfils many mobile app requirements, but you can make it even better by taking advantage of components that are specifically designed for mobile app development, such as those available in the V-Play Apps SDK , which provides components on top of Qt to simplify and accelerate mobile app development with Qt.

V-Play Apps components were designed with mobile-first in mind. This means you get components used by the most successful and popular mobile apps on iOS and Android as cross-platform components.

This is the first part of the “Mobile App Development with Qt” series. In the second part, you will learn about the differences between platforms and how you can support these differences with a shared code base using Qt and V-Play Apps.

As soon the second part is released, the link will be added here.

The post Mobile App Development with Qt Part 1 – Top Considerations for Choosing Your App Development Framework appeared first on Qt Blog.

CMlyst is a Web Content Management System built using Cutelyst, it was initially inspired by Wordpress and then Ghost. So it's a mixture of both.

Two years ago I did it's first release, and since them I've been slowly improving it, it's been on production for that long providing www.cutelyst.org web site/blog. The 0.2.0 release was a silent one which marks the transition from QSettings storage to sqlite.

Storing content on QSettings is at first quite interesting since it's easy to use but it showed not suitable very fast, first it kept leaving .lock files, then it's not very fast to access so I had used a cache with all data, and a notifier updated that when something changed on the directory, but this also didn't properly triggered QFileSystemWatcher so once a new page was out the cache wasn't properly updated.

Once it was ported to sqlite, I decided to study how Ghost worked, this was mainly due many Qt/KDE developer switching to it. Ghost is quite simplistic, so it was very easy to try to provide something quite compatible with it, porting a Ghost theme to CMlyst requires very little changes due it's syntax being close to Grantlee/Django.

Due porting to sqlite it also became clear that an export/import tool was needed, so you can now import/export it in JSON format, pretty close to Ghost, actually you can even import all you Ghost pages with it, but the opposite won't work, and that's because we store pages as HTML not Markdown, my feeling about markdown is that it is simple to use, convenient to geeks but it's yet another thing to teach users which can simply use a WYSIWYG editor.

Security wise you need to be sure that both Markdown and HTML are safe, and CMlyst doesn't do this, so if you put it on production be sure that only users that know what they are doing use it, you can even break the layout with a not closed tag.

But don't worry, I'm working on a fix for this, html-qt is a WHATWG HTML5 specification parser, mostly complete, but the part to have a DOM, is not done yet, with it, I can make sure the HTML won't break layout and remove unsafe tags.

Feature wise, CMlyst has 80% of Ghost features, if you like it please help add missing features to Admin page.

Some cool numbers

Comparing CMlyst to Ghost can be trick, but it's interesting to see the numbers.

Memory usage:

• CMlyst uses ~5MB
• Ghost uses ~120MB

Requests per second (using the same page content)

• CMlyst 3500/rps (production mode), 1108/rps (developer mode)
• Ghost 100/rps (production mode)

While the RPS number is very different, on production you can use NGINX cache which would make the slow Ghost RPS not a problem, but that comes to a price of more storage and RAM usage, if you run on an AWS micro instance with 1GB of RAM this means you can have a lot less instances running at the same time, some simple math shows you could have 200 CMlyst instaces vs 8 of Ghost.

Try it!

https://github.com/cutelyst/CMlyst/archive/v0.3.0.tar.gz

Sadly it's also liked soon I'll be forking Grantlee, the lack of maintenance just hit me yesterday (when I was going to release this), Qt 5.7+ has changed QDateTime::toString() to include TZ data which broke Grantlee date filter which isn't expecting that, so I had to do a weird workaround marking date as local to avoid the extra information.