Qt vs. HTML – The Full-Stack Comparison

Today, I wanted to announce the release of a new white paper on a, if not new, still fascinating and, honestly speaking, a little controversial topic. A while back, I published a white paper with the provocative title “Qt vs HTML5 – a practical comparison”. The goal was to highlight the differences in usability of the two technologies and performance of the resulting application based on a real-life experiment.

GitQlient: The new UI (Part II)

In the previous entry of this series of posts I introduced the change I planned to transform QGit in a new app and plugin called GitQlient.

In the old QGit there was a mix of UI files, in place widgets and classes that handle data and return widgets because... why not? A mess. For GitQlient, I separated the UI by scopes and I changed the main window for a QWidget so I can easily integrate it in the plugin.

GitQlient: The new UI (Part II) first appeared on My C++ & Qt blog - Cesc M..

Qt for Android better than ever before

As you already know KDAB is the largest independent contributor to Qt code. Of course we didn’t get lazy and we’ve added a lot of cool stuff to Qt 5.14.

In this article I’m going to write about the super cool stuff that we’ve added to Qt 5.14 for Android.

Android multi arch build in one go

Folks, this is the biggest feature added to Qt on Android since I made the Qt on Android port! I dreamt on this change for a very loong time! I found that is possible to add such support to qmake by mistake :). I had to do some work on Windows (which is not my platform of choice) and there I found that debug and release builds are different on Windows, the makefiles generated by qmake will build twice your source files.

This was exactly what I needed to add multi abi for Android! A few days later I had a WIP patch and, with the help of The Qt Company people, we landed the change in Qt 5.14 alpha!

Let’s see what is new:

  • First and foremost from Qt 5.14 there will be a single Qt for Android SDK. Same as the Android NDK, the Qt for Android SDK contains the libs & plugins built for all Android platforms (armv7a, arm64-v8a, x86, x86_64). If you’re building Qt from sources and you want to build only for e.g. arm architectures, you can filter them using the new -android-abis configure parameter:
     ./configure -android-abis armv7a,arm64-v8a -developer-build -xplatform android-clang -android-ndk /home/bogdan/android/ndk-bundle -android-sdk /home/bogdan/android
    
  • If not specified otherwise, your application will be built by default for all these platforms in one go. You can filter which ABI(s) you want to build for using the ANDROID_ABIS qmake variable, this is useful while you develop your application, to cut the build time. Build only for arm64-v8a
    qmake ANDROID_ABIS="arm64-v8a"
    

    Build only for armv7a and arm64-v8a

    qmake ANDROID_ABIS="armeabi-v7a arm64-v8a"
    

Yes, we changed Qt Creator to make it easier to choose which platforms you want to build for, check the next image:

In order to support this super cool feature we had to change a few things:

  • All the .so files produced by qmake are suffixed with the android abi. If you’re using Qt library/plugins classes you don’t need to take any actions, otherwise qmake sets QT_ARCH variable for the ABI you’re currently building, so you can use it to know which suffix you need to add e.g:
    # ...
    android: DEFINES += LIBS_SUFFIX='\\"_$${QT_ARCH}.so\\"'
    # ...
    

    Then you can use LIBS_SUFFIX macro in your srcs.

  • Because on android we have only one libs folder level, we must rename all the [qml] plugins to make sure we don’t have any name clashes. We use the following naming scheme:
    lib + "plugin/path".replace('/','_') + {plugin_name} + _$${QT_ARCH}.so.
    

    If you have a plugin which uses ANDROID_LIB_DEPENDENCIES qmake variable make sure you use the previous naming scheme. Here https://codereview.qt-project.org/c/qt/qtgamepad/+/273676/2/src/gamepad/gamepad.pro you can see how we did it for Qt Gamepad module. Initially I did the renaming from androiddeployqt, but soon I found that this breaks the plugins debugging, as the gdb won’t find the renamed files on the Qt folders, and for me not being able to debug my precious plugins was unacceptable.

Android App Bundles (aab)

I’m going to tell you a secret, Android App Bundles were the main reason for doing the multi arch build in one go :). Without multi arch build in one go you can’t have aab, well at least not without a lot of work, pain and sorrow. Because I’m a happy, lazy person, I don’t like to work more than I must, therefore I had to find a solution to make our life easier. In Qt 5.14, it’s very easy to build an .aab file:

$ make aab

it’s all you need to run on a terminal to build it!

Same as above, I added a new option to Qt Creator to enable .aab packages with a single check box, see the following image:

Load Qt plugins directly from android libs folder

Since Qt 5.14, the Qt plugins were stored to android assets and then extracted to your home folder at the very first start. There are two problems with this approach:

  • The very first startup time needed more time to extract all the files
  • It occupies more disk space

Starting with 5.14, instead of bundling the plugins and QML resources in assets and extracting them on first start, Qt now creates an .rcc file and registers it before invoking the main function.

Other pretty nice changes

  • Same as above, in Qt 5.14 you can easily create an apk from the command line:
    $ make apk
    

    is all you need to type on your terminal to create it.

  • Reworked assets support – the new version fixes QDirIterators, also it lists all the files and folders.
  • NDK r20+ is needed as I updated the clang mkspecs to follow https://android.googlesource.com/platform/ndk/+/ndk-release-r20/docs/BuildSystemMaintainers.md guide. With this change, let’s hope we’ll have less issues with newer NDK versions, as you probably noticed Google folks are restless and they are doing their best to break other tools from time to time :).
  • Drop gcc support – this was a change that personally I didn’t like to do it, but I had to, mostly because it was quite challenging to support NDK r10e (the recommended NDK for gcc).
  • Last but not least, an easy way to run tests on Android:
    $ make check
    

    It’s all you need. For more details and tweaks about it, you can come to my Qt World Summit presentation ;-).

  • See more about KDAB Talks at Qt World Summit

The post Qt for Android better than ever before appeared first on KDAB.

Change in open-source licensing of Qt Wayland Compositor, Qt Application Manager and Qt PDF

The license of Qt Wayland Compositor, Qt Application Manager and Qt PDF will change from LGPLv3/Commercial to GPLv3/Commercial. Change becomes in effect with the Qt 5.14 release.

Since January 2016 most of the new Qt Add-On modules have been licensed under GPLv3 license for open-source users in addition to the commercial licensing option. We use GPLv3 license for the selected Qt Add-Ons in order for those making closed-source applications or devices to pick the commercial option when using these add-on modules, while still providing the functionality under an open-source license for open-source applications.

In order to increase the amount of GPLv3/Commercial licensed Qt Add-Ons the license of Qt Wayland Compositor, Qt Application Manager and Qt PDF is changed. Going forward, these modules are no longer available under LGPLv3 license option. Qt Wayland Compositor and Application Manager are mainly used in complex multi process embedded systems. These are not used on Desktop or Mobile, and not by majority of the embedded developers either. Qt PDF is a new module, which has not been released earlier despite the pre-release code being available.

The following Qt Add-Ons are licensed under GPLv3 for open-source users:
• Qt Charts
• Qt CoAP
• Qt Data Visualization
• Qt Device Utilities
• Qt KNX
• Qt Lottie Animation
• Qt MQTT
• Qt Network Authentication
• Qt Quick WebGL
• Qt Virtual Keyboard

For all of these modules, the commercial license option is available. In addition to the Qt Add-Ons, the Qt for WebAssembly platform as well as Qt Creator and other tools are licensed under GPLv3/Commercial.

The change in licensing of Qt Wayland Compositor, Qt Application Manager and Qt PDF is implemented in the coming days to be in effect by Qt 5.14 release timeframe and later releases.

For further information on Qt licensing, please take a look to the FAQ: https://www.qt.io/faq/  

If you have any questions or concerns about licensing of Qt, please contact us via the online form or email to legal@qt-project.org

Qt 5.14.0 Beta1 Released

I am happy to announce that Qt 5.14.0 Beta1 is released today. We will release updates as Beta N regularly until we are ready for RC. Current estimation for RC is 12th November 2019, see the schedule from 5.14 wiki.

Option to provide anonymous usage statistics enabled

The option to provide anonymous usage analysis from Qt Creator 4.10.1 has been enabled today. Please read on to understand what kind of data we are collecting when you choose to send anonymous usage statistics, why we are interested in this and how is the data collected. 

Why to collect usage statistics? 

The Qt Company has an increasing need to better understand, how Qt products are used by both commercial and open-source users. This information is being collected from bug reports and suggestions, using customer and user surveys, and Qt mailing lists. Now, we want to offer an option for anonymous data collection in Qt Creator as well. The collected data helps to understand what Qt versions developers use, which compilers are used, how much Qt Creator itself is used. This data will be used for improving Qt and Qt Creator to be even better fit for the needs of our users. 

GitQlient: The evolution of QGit (Part I)

Some time ago I wanted to write a plugin for QtCreator where I could handle Git repositories with a GUI. After discovering QGit I decided to "fork" it, clean it, refurbish it and add a new UI.

From that project a new app has rised: GitQlient. Can be used both as a standalone app or as a QtCreator plugin.

In a series of posts I'll explain how I achieve it.

GitQlient: The evolution of QGit (Part I) first appeared on My C++ & Qt blog - Cesc M..

A fast and thread-safe pool allocator for Qt - Part 2

In part 1 of this blog series, we developed a pool allocator that is optimized for small allocations. We confirmed that we do that a lot in Qt when we allocate QEvent or QObject instances, and a specialized allocator might be useful for application developers as well. So far, our solutions will allocate complete pages of memory as needed, and hand out memory chunks of a fixed size that is specified at compile time through a template parameter. It supports different threading models, with different tradeoffs regarding performance, memory efficiency, and concurrency. The results were giving us a very promising performance, beating the general-purpose allocators by a factor of 3-10 in our multi-threaded benchmarks.

QBSP for TechNexion boards added to downloads

In the past we have been talking about what is QBSP here: https://www.qt.io/blog/2018/12/14/board-support-package-commercial-build-enablers-qt-partners and from the official documentation here: https://doc.qt.io/QtForDeviceCreation/qtdc-qbsp.html

We are happy to announce that our Hardware Technology partner TechNexion has just released new Qt Board Support Packages (QBSP) for their hardware platforms. The QBSP's are now available also for TechNexion iMX8MQ and iMX8M-Mini boards for Qt 5.12 LTS and Linux hosts. You can find them through your Qt Account under account.qt.io/downloads.

Cutelyst 2.9.0 and simple-mail-qt 1.4.0 released!

Today I'm rolling out two releases, Cutelyst, which is a Qt Web Framework and SimpleMailQt which is a SMTP client library.

Cutelyst has got many bug fixes, a few API additions, some docs fixes, and most importantly it fixed a memory leak introduced in 2.8.0 that makes applications using chained actions leak.

I was planning for a v3 due some changes I was planning but changed my mind and I think the current version can be kept for a little longer, my current plan is to add SNI support for the WSGI module so that a sort of Virtual Hosts is possiblem.

The ideia for Virtual Hosts is that you can get rid of Nginx (or any front end server) if you want and can, the front servers are great, but they do a work that could be avoided. When a request arives the server it has to parse, identify to which application it has to redispatch and create a new request (in HTTP/FastCGI/whatever), on single core servers the OS will put it to sleep, wake cutelyst, which then parses the request again, creates a reply, which is then parsed by the front and recreated for the client.

Of course they are fast and all, but surely if it could be avoided would be great, on an IPv6 only world I'd just put a different IP for each application and be done, but not the reality now do I'll try to see if a new Cutelyst application could load all your applications in a single process. It's just an idea atm.

SimpleMailQt also got quite a few bug fixes, most importantly it got it's CMake modernized so it builds fine on Windows now.

For those that don't know SimpleMailQt, it was based on a SmptClientForQt with a port to CMake and many API changes to be more Qt style. But it's a blocking library which also doesn't do pipelining, so for v2 I'll be creating a new async engine that will be async and do pipelining if the server supports.

Have fun:

https://github.com/cutelyst/cutelyst/releases/tag/v2.9.0 https://github.com/cutelyst/simple-mail/releases/tag/v1.4.0

Introducing KDToolBox

At KDAB we invest a significant amount of efforts in research and development. We are always looking for new tooling, libraries and utilities that can make our job easier and improve the C++ and Qt ecosystems. Ultimately, the gained knowledge and skills make our customers happier.

As part of this process we develop lots of code, usually starting as small experiments and/or proof-of-concept. Some of those experiments mature and become fully fledged solutions, such as our famous GammaRay, the introspection tool for Qt applications; hotspot, the GUI to Linux perf; and heaptrack, a heap memory profiler.

Some other experiments however do not reach the level of being a standalone product. Nonetheless, we believe that other users may find them useful when developing their own applications; therefore, we want to share our discoveries and expertise.

For this reason, in the past few months we have started publishing some of our results on GitHub. Say hello to KDToolBox: KDAB’s collection of miscellaneous useful C++ classes and stuff. Yes, we could have not picked a more buzzword-friendly name 🙂

In the next blog posts we are going to discuss more in detail some of the goodies that you can find in KDToolBox.

In the meanwhile, you can download KDToolBox from its git repository here: https://github.com/KDAB/KDToolBox.

Happy hacking!

The post Introducing KDToolBox appeared first on KDAB.

KDAB talks at Qt World Summit 2019

The agenda is published and KDAB engineers are offering a wealth of technical talks this year.

Optimizing the Rendering of Qt Quick 2 applications, Giuseppe D’Angelo

If you have ever wondered how Qt Quick applications are rendered to the screen, and how to use that knowledge to find and fix performance problems, then this talk is for you.

Qt Quick 2 applications are notably easy to write. With just a few lines of QML code we can create compelling, animated, fluid, 60FPS user interfaces.

From time to time, however, we may face performance problems in our UI layer, especially in constrained hardware environments (mobile or embedded). In order to tackle these problems we need to understand the foundations of Qt Quick 2’s rendering, and how to design our code in order to extract the maximum performances from the underlying hardware.

And while it is true that premature optimization is the root of all evil, avoiding premature pessimization is also extremely important, especially at early stages of design of a complex application.

In this talk we will introduce the main principles behind profiling and optimizing the rendering of a Qt Quick 2 application.

We will start by discussing how Qt Quick 2 renders a scene – namely, through its scene graph and via OpenGL calls.

We will see how to gather information about how effectively Qt Quick is rendering a scene. Some of this information is available via “secret switches”, while other requires the usage of external tools, which is therefore necessary to master.

Finally, we will discuss how to fix some of the most common performance problems: poor batching, excessive overdraws, fill rate limitation, and poor texture memory utilization.

Practical experience with QML application is required, and some OpenGL knowledge is beneficial (but not necessary).


Testing your code for security issues with automated fuzzing, Albert Astals Cid

Writing secure code that deals with potentially untrusted data (parsers, importers, etc) is always hard since there are many potential cases to take into account.

One of the techniques used to improve the security of such code is fuzzing.

Fuzzing involves providing invalid or random data to a given piece of code to test its behaviour.

Modern fuzzers are smart enough to understand what needs to be changed in the input to make the code go through a different code path making testing faster and more complete.

oss-fuzz is a Free set of tools to make fuzzing of C/C++ code easier. It is comprised of various scripts and docker images, which, for example, have the base system libraries already compiled with the sanitizers.

Coupling a fuzzer with the compiler sanitizers (asan, ubsan, msan) gives even better results since these sanitizers will make sure the code is run more strictly.

In this session we’ll show how to fuzz a C++ codebase, as well as give you an update on how Qt is using these tools.


Model models: tools for making better behaved models, André Somers

Qt QAbstractItemModel API is used for both widgets and QML applications where it plays a central role for cases where there is a need to present larger quantities of data. For optimal performance, UI experience and to be able to use the insert, remove, move and displaced transitions on the QML ListView it is imperative that updates are signalled properly and as finely-grained as possible. But how do we deal with back-ends that don’t deliver enough data to do this? What if they just signal ‘changed’ or give us a whole new list without indicating what changed?

Instead of relying on repetitive, hard-to-read and error-prone code or in the worst case relying on a model reset, I will present a generic approach leading to a simple drop-in solution to deal with data that comes in in bulk which results in proper, finely-grained updates to the model. A similar problem is providing all needed signals in case the model needs to be sorted. While a QSortFilterProxyModel does a good job doing the actual sorting, it does not provide the required signals to allow animating items moving in a QML ListView when the value of items changes or when the sort role or -column changes. In order to fix this, I will present a specialized proxy model that does enable this.

Using these tools will help you make your models behave like “model” models.

QML Component Design: the two-way binding problem, André Somers

Did you ever create QML components that both display and manipulate a state that is stored in some kind of back-end? How do you ensure a property binding set by the user of your component stays intact? What should happen if that backed is slow, or rejects your changes?

In this talk, we will explore this problem in some more detail, and demonstrate a few possible solutions that deal with the challenges raised in different ways. The goal is that at the end of this talk, you will have the tools available to make UI components that behave predictably and are intuitive to use in your applications.


Improving your code using Clang Tooling, Kevin Funk

Clang is a C/C++ compiler frontend which parses C++ source code. Since the beginning of its development, the Clang ecosystem had a strong focus on providing tooling around C++. Several tools exist, which help writing or debugging C++ or even Qt code.

This talk will introduce you to several highly valuable tools backed by Clang, such as the Clang compiler frontend itself (for static analysis), the Clang static analyzer (for static analysis), clang-tidy (for static analysis, linting & refactoring of source code), clang-format (for enforcing a coding style on your code), Clang Sanitizers (dynamic analysis) and last but not least: Clazy (a compiler plugin for Clang that has additional checks for Qt code).

For each tool in this presentation, we’ll do a brief introduction about its capabilities and then live-demonstrate its usage on a few code examples. We’ll also demonstrate how the Clang tools can be used on projects using build systems other than CMake, by applying a few tricks.

Clang is available on all major platforms, thus these tools can be used freely on either Windows, Linux or macOS. (With some limitations of the Clang Sanitizers on the Windows platform).

Git and Gerrit for working with and on Qt, Kevin Funk

A basic knowledge of Git is essential if you want to apply patches back to Qt or try out a not yet released version of Qt. In this talk we’re going through the most basic bits about modern software development with the code version control system Git. Beginning with the basic concepts, such as the initial setup, checking out code we will show how to manage and commit changes as well as navigate through the Git history.

Building on that knowledge, we’ll demonstrate doing exactly the same using the Git integration inside the QtCreator IDE, which provides similar functionality via a convenient graphical interface.

After having done that, we will show how to get started with the code review system in place for the Qt ecosystem, Gerrit. As part of this talk we’ll discuss how to set up your Gerrit account, how to upload your SSH keys and how to configure your Git checkout to be ready to work with Gerrit. We’ll do a small change on Qt module checkout, verify we did not break existing functionality, and then submit our change for review.


Qt 3D Node Editor and Shader Generator, Paul Lemire

More and more frameworks and tools are providing higher level of development through the use of Node Editors to create code, behaviors or entire applications.

Since Qt 5.12, Qt provides support for loading a tree of nodes and convert these to generate OpenGL GLSL shader codes for Qt 3D.

This can be harnessed to create a single shader description that can then be translated into different languages.

This talk will present that part of the framework, show how it is used and discuss possible ideas of how that could be extended to target completely different type of features in the future.

What’s new in KUESA and Qt 3D, Paul Lemire

Various things have been overhauled and improved in both KUESA and Qt 3D over the past year. This talk is about showing what has changed and defining where we’d like to go with both KUESA, the designer-developer workflow package, and the Qt 3D module.

Migrating from MFC to Qt, Nicolas Arnaud-Cormos:

Microsoft Foundation Class Library (MFC) is a legacy C++ object-oriented library on Windows that exists since the dawn of Windows. It has been replaced lately with more up to date framework, but MFC legacy code still widely exists.

While Qt and MFC are both over 25 years old, that’s where the similarity ends. Qt is actively maintained by a vibrant developer community, upgraded regularly to embrace the latest programming improvements, and expanded to cover new devices and operating systems. Qt is then a natural candidate for replacement of MFC.

In this talk, we will discuss the strategy and steps to migrate a MFC legacy code base to Qt, how to map MFC code to Qt, as well as some of the traps to avoid.

Practical application scripting with QML, Kevin Krammer

In my talk “When all goes according to script” at Qt World Summit 2015, I explored the fundamentals of using the QML environment for the purpose of in-application scripting.

In this follow-up I am going to look into more practical aspects, especially on how the powerful declarative approach in QML allows very easy handling of asychronous scripting tasks.

The format will be a series of live-demos with Qt applications which either have been extended with such a scripting environment or which have even been built specifically around this capability.

Similar to the original talk the goal is to show once again that QML is a versatile and powerful component for all Qt application development, above and beyond the already established use case of building advanced UIs.

Full-stack Tracing With LTTng, Milian Wolff

We all love and use C++ because of its performance. But how do we actually measure the performance of an application? How do we check whether an application is CPU- or I/O bound? How do we see if our application is influenced by others running on the same system?

There are many good and valid answers to these questions. Tracing certainly is a very valuable addition to everyone’s toolset. It can offer in-depth insights into what a system is doing and why an application is performing in a given way. Done properly, we can use it to piece together multiple pieces of the picture: How is our hardware utilized, what is the kernel doing, what is my application doing?

In this talk, we will give an introduction to LTTng, a tracing toolkit for Linux, and show how it can be applied on embedded Linux systems to get an answer to the following question: What can I do to optimize the startup time of my application?

We will talk about configuring Qt and LTTng properly. We will discuss the most useful kernel trace points and demonstrate the tracing subsystem in Qt for custom user space trace points. And we will look at how to analyze the collected data in a way that doesn’t make you want to pull your hair out.

The contents of this talk stem from the experience of successfully optimizing automotive Qt applications on embedded Linux applications. The lessons learned apply to a much broader audience and can also be used with other tracing toolkits such as ETW on Windows.


QStringView — Past, Present, and Future, Marc Mutz

Since QStringView was added in Qt 5.10, not much has happened, and the presenter duly asks for forgiveness for having stepped away from QStringView development for two years. But he’s back now, and Qt 5.14 will contain a significantly more complete QStringView (and QLatin1String) ecosystem than 5.13 did.

If you do string processing with Qt, this talk is for you. After a very brief recap on QStringView’s general purpose in Qt, we will look at what’s new in Qt 5.14 with respect to QStringView and, time permitting, take a brief look into the near future.


Testing & Profiling Qt on Android, Bogdan Vatra

In this session we are going to learn how to test and profile our Qt application on Android.

The talk will cover:

  • how to use Qt Test on Android
  • how to use Google tools to do profiling

 

 


Qt on the second Screen, Christoph Sterz

Companion Apps, VNC remoting, streaming WebGL to the Browser or compiling your Code to WebASM – Adding a secondary screen to your application can either extend its functionality or the physical range for users operating it.

Especially for Embedded Devices, offering remote monitoring, configuration or off-site maintenance adds benefit to users used to mobile and opens quick paths for support-teams to help effectively.

This talk will summarize all options Qt has to offer for these needs and the usual paradigms to follow when you design your software to reach out further.

 


See the full agenda here.

Check out the Training courses on the 4th and sign up for Qt World Summit 2019.

The post KDAB talks at Qt World Summit 2019 appeared first on KDAB.

KDAB at Squish Days Europe, Munich

KDAB will be supporting our training partner, froglogic, at this event in Munich dedicated to Squish, the automated GUI tester we are proud to support.

Complete with live demo-ing, Tobias Naetterlund, KDAB’s foremost Squish expert, will be giving a talk showing how to control multiple clients simultaneously on one or more machines, using this versatile tool:

Load testing with Squish

In a client-server architecture, ensuring the server can run perfectly, even under load, is as vital as making sure the client functionality is correct. In some cases, you can have your Squish tests talk directly to the server in order to test the functionality under load, but in order to set up as realistic server usage scenarios as possible, it would be beneficial to instead use Squish’s playback functionality for controlling multiple clients simultaneously, and have them talk to the server the way they normally would during daily usage.

In this talk, the presenter will outline an approach for load testing a server backend by controlling multiple client frontends simultaneously. We will discuss a number of challenges you may run into, and various approaches of attacking them. As we will start from the basics, no previous Squish knowledge is necessary.

Register for Squish Days Europe

Get KDAB’s Squish training for your team.

The post KDAB at Squish Days Europe, Munich appeared first on KDAB.

AsteroidOS - the open source watch

So I get a message regarding changes needed to Sensor Framework and QtSensors to add heart rate sensor support for AsteroidOS. AsteroidOS is an open source operating system for watches. It uses OpenEmbedded and Yocto to build the system image and kernel that you can flash to a small group of Android watches. The UI is based on Qt and Qml.

I thought about it for approximately 30 seconds and I bought a used LG Urbane watch. Which is listed on the Install documentation for the OS, as one of the watches that can run AsteroidOS. I choose LG, as I am partial to their Smart TV's, which happen to run Qt and QML.

First issue I ran into was that adb did not see the watch on WearOS, even in developer mode, but once I changed the usb cable to a good, solid cable (actually is an old Nokia cable that still works like new!), I was then able to flash the pre-built AsteroidOS 'nightly' build image on it. You might want to backup the image on the watch before you do, unlike what I did. First flash resulted in a boot loop, so I flashed the image again, and this one booted!



In order to test new sensors code, I need to build the thing. Essentially, it was simply to git clone the repo, run a script, and build the image. Too easy! Luckily I have a fast development machine and it did not take too long to complete.
Again I had to flash it two times. As long as I can get into the fastboot screen, everything is ok.

WearOS has a wrist gesture sensor, which in WearOS, turns on the display when the user flicks their wrist. iOS does this as well. AsteroidOS does not yet have support for utilizing this, so that is one of the first things I would like to fix. Neither QtSensors or Sensor Framework has support for this sensor yet. Since it is open source and I am familiar with sensor API's that run on it, I can fix this on my own!

You can read more about Qt development for Mobile and Embedded devices in the book Hands-On Mobile and Embedded Development with Qt 5
















































You can learn more about Yocto and embedded programming with Qt in my book Hands-on Mobile and Embedded Programming with Qt 5

QMqtt & QWebAssembly

Qt for WebAssembly is an exciting new platform for Qt. It means that Qt applications can run in a web browser. This means that deploying a Qt application is as easy as copying the files to your properly configured web server and handing out the url, for your users to run in their web browser.

Mqtt is a machine to machine communication protocol, which is used for messaging in IoT. Websocket is a two way communication protocol between a web browser and a web server.

QtMqtt has been ported to run on the WebAssembly platform, using QtWebSockets as it's transport. There is a catch to getting it working, however. That catch is that you need to use the WebSocketIODevice class that is in the QtMqtt websocketsubscription example app. WebSocketIODevice depends on the QtWebSocket module.

You need to copy websocketiodevice.h and websocketiodevice.cpp into your project, using the WebSocketIODevice as QMqttClient's transport.

In a nutshell, at a minimum,  code such as this:

QMqttClient m_client
WebSocketIODevice m_device;
m_device.setUrl(m_url);
connect(&m_device, &WebSocketIODevice::socketConnected, this, [this]() {
    m_client.setTransport(&m_device, QMqttClient::IODevice);
}

Then you can use the QMqttClient as normal.

You can read more about Qt for WebAssembly, QtMqtt and QtWebSockets in the book Hands-On Mobile and Embedded Development with Qt 5

3D – Interactions with Qt, KUESA and Qt Design Studio, Part 2

In my last post, I went through a method of creating a simulated reflection with a simple scene. This time I’d like to take the technique and apply it to something a bit more realistic. I have a model of a car that I’d like to show off in KUESA™, and as we know, KUESA doesn’t render reflections.

Using the method discussed last time, I’d need to create an exact mirror of the object and duplicate it below the original, and have a floor that was partially transparent. This would be expensive to render if I duplicated every single mesh on the high poly model. Here, the model is X triangles – duplicating it would result in Y triangles – is it really worth it for a reflection?

However, if I could take a low poly version of the mesh and make it look like the high poly mesh this could then work. I could bake the materials onto a low poly mesh. Easy to do in blender.

Here I have a low poly object as the created reflection, with the baked materials giving the impression of much higher detail than physically exists. Using the same technique of applying an image texture as an alpha channel, I can fade out the mesh below to look more like a reflection.

To further the illusion, I can also blur the details on the baked materials – this, along with the rough texture of the plane, gives more of a reflective look, especially when you consider that a rough plane would not give an exact reflection:

The good news is, it produces an effect similar to a reflection, which is what we want.

This is all very well for a static model, but how can I deal with an object that has animations, such as a car door opening? I’ll look into this in the next post.

The post 3D – Interactions with Qt, KUESA and Qt Design Studio, Part 2 appeared first on KDAB.

Android 64-Bit Support with Qt and Felgo Cloud Builds

The Android world is moving to 64-bit and we all have to follow along. Google Play Store is sending out Emails to inform developers about the upcoming changes in August 2019 and August 2021. Here’s what you need to know, how it will affect you as a developer and why any Qt app should use Felgo Cloud Builds to save a lot of time and trouble.

Source: Google

 

Before we go into details, here is a quick summary of what Felgo Cloud Builds offers for any Qt and Felgo app:

  • Store your signing information persistent. With Qt Creator, you will have to re-add them every time you close your project.
  • Build the app for both 32-bit and 64-bit architectures simultaneously.
  • Increment the version code for each build automatically.
  • Generate new license keys for each build version automatically.
  • Upload the generated APKs to the store, so you can access them from your Artifact Library.

All those manual steps are automated with the click of a button. Let’s take a closer look at the process.

On a side note, Apple also switched to 64-bit for iOS a couple of years ago and today they only support 64-bit.

1st August 2019: Google Play no Longer Accepts Submissions without 64-Bit Architecture

This deadline does not affect the availability of any published app that is already live in the stores. Users will still be able to see and download your app from the Google Play store. If you want to upload new apps, or updates you will need to provide additional 64-bit architectures.

From their documentation: All new apps and app updates that include native code are required to provide 64-bit versions in addition to 32-bit versions when publishing to Google Play.

So what do you need to do before this deadline comes? Actually, nothing.

None of your existing apps will be affected by that deadline. You will only have to include 64-bit for any future app submission. You will learn how to do this later in this post.

There is another small new requirement that does affect any project though. The targetSdkVersion of any app must be set to at least 28 starting with 1st August. You can find this value in AndroidManifest.xml in the “android” folder of your project:

<uses-sdk android:minSdkVersion="16" android:targetSdkVersion="28"/>

1st August 2021: Google Play no Longer Serves Apps without 64-Bit Architecture

This deadline will affect all apps in the Play Store. If your app does not include the 64-bit architecture, users will no longer be able to find and download it, if their device supports 64-bit.

From their documentation: Google Play will stop serving apps without 64-bit versions on 64-bit capable devices, meaning they will no longer be available in the Play Store on those devices.

So in about 2 years from now, all your live apps will have to include the 64-bit architecture. No need to panic!

How to Support Android 64-bit in Your Qt and Felgo Apps

You can choose between manual building and deployment, or automating the whole process using Felgo Cloud Builds. We will explain both options below. We highly recommend to use Cloud Builds for faster and easier building and especially for store deployment.

1. Build your Android App with 64-Bit manually using Qt Creator

Install the 64-bit Android Package for Use with Qt Creator

If you want to use manual deployment, you need to install the new Android 64-bit package first. Open the maintenance tool located in your Felgo installation directory, choose “Add or remove packages” and you will see a new package available.

Package selection in maintenance tool.

 

To build the Android 64-bit architecture you need to install the new ARMv8 package, then it will be available as a kit in Qt Creator.

With a total of 3 Android packages offered, you might be wondering which you need to install and which you need to provide for an app submission. Here’s a short summary to help you decide:

  • x86: With a market share of about 1.5% (and declining), this Intel 32-bit architecture is basically gone. If you plan to use the Android simulator for testing on your desktop, you can consider installing this package. For Google Play app store submissions, you can safely skip this architecture.
  • ARMv7: The 32-bit architecture is widely used and was, up until now, the primary architecture used for app store submissions. It is still recommended to install this package and include this architecture in your app store submissions.
  • ARMv8: This is the new 64-bit architecture. App store submissions after 1st August 2019 need to include it.

We will summarize the important steps for building and including the new 64-bit architecture for app store submissions here.

Build your Android App with 64-Bit using Qt Creator

Google Play offers 2 options to upload different architectures for a single submission.

The first one is called “Android App Bundle” and is not yet supported by Qt. However Qt already announced working on support for this format. This allows to combine all architectures into a single archive, upload it to Google Play and Google will serve the correct architecture for each user.

Until then, we use the second option, which is uploading individual APKs for different architectures. This is very straightforward, and there is only one very important detail that needs to be considered. Every APK must have a different version code set. This also means that you need to generate a separate Felgo license key, which is bound to the version code, for every architecture.

We prepared a little code example for your *.pro file, to use different version codes and license keys depending on the architecture:

# Project identifier and version
# More information: https://felgo.com/doc/felgo-publishing/#project-configuration
PRODUCT_IDENTIFIER = net.example.yourapp
PRODUCT_VERSION_NAME = 2.0.1

contains(ANDROID_TARGET_ARCH, arm64-v8a) {
 PRODUCT_VERSION_CODE = 2011 # add 1 as suffix
 PRODUCT_LICENSE_KEY = "abcd" # license key for this version code
} else {
 PRODUCT_VERSION_CODE = 2010 # add 0 as suffix
 PRODUCT_LICENSE_KEY = "efgh" # license key for this version code
}

# Optionally set a license key that is used instead of the license key from
# main.qml file (App::licenseKey for your app or GameWindow::licenseKey for your game)
# Only used for local builds and Felgo Cloud Builds (https://felgo.com/cloud-builds)
# Not used if using Felgo Live
# PRODUCT_LICENSE_KEY = "" # removed this, as already set above

You can update your existing *.pro file with this code, to make it easier to manage the different architectures. Note that Cloud Builds will require a different format, described later.

After building your app for each architecture, you will end up with 2 APKs, that you can upload with your next submission to Google Play.

If you have not yet used Android deployment with Qt or Felgo, check out the full Android deployment guide with all recommended tooling versions and important hints and tips.

2. Build your Android App with 64-Bit using Felgo Cloud Builds CI/CD

If you are not a fan of fiddling around with native frameworks or want to automate your building and publishing process, Felgo Cloud Builds got you covered.

While you can use the Felgo Live Code Reloading for development on your mobile phone without any native frameworks installed, Felgo Cloud Builds closes the gap to your testing and distribution channels.

 

How to use Cloud Builds to Build your Android App for 64-Bit

The Android 64-bit architecture is enabled by default when you configured the Android platform in Cloud Builds. You now also have the option of automatically increasing the version code for each build, and automatically generate license keys for those builds.

This is especially useful for the new Android 64-bit architecture, which requires 2 distinct APKs, with different version codes (and therefore different license keys).

Enable it in your project settings, like this:

Cloud Builds project settings.

 

If you trigger a new build, you will now have the option to update the license key. If you already have triggered a build using this feature, you will see a suggested new version code in the dialog. For Android 64-bit, the version code is also automatically increased by 1.

New build dialog, with option to auto-increment version code and create license keys.

 

After building you can download those APKs and use them for your manual submission, or also automate this with connecting your Google Play account.

Manual download of APKs after build finished.

 

To enable app store uploads on Android, all you need is to provide the Google Play API JSON file of your Play Store account.

Upload of API JSON in Cloud Builds project configuration.

 

You can find general step-by-step instructions on how to use Felgo Cloud Builds here: Continuous Integration and Delivery (CI/CD) for Qt and Felgo

 

Start using Felgo Cloud Builds
 

Important Migration Steps for Older Projects

If you want to make use of the new convenient feature of automatic version code increase and automatic generation of license keys, you might need to apply some changes to existing apps.

If you are unsure about any of the listed changes, you can just create a new empty project from the Qt Creator project wizard (using Felgo 3.2.0 or later), and compare the following files with your own:

  • *.pro project configuration file, found in the root directory of a project.
  • main.cpp entry point file, found in the root directory of a project
  • build.gradle Android build configuration, found in the “android” folder of a project.
  • Project-Info.plist iOS configuration file, to also use the new features for iOS builds, found in the “ios” folder of a project

The *.pro file needs to contain properties for the identifier, version name, version code and license key. If you use Felgo plugins, also make sure to move the “FELGO_PLUGINS” definitions to the root level, and not inside the “ios” block of your *.pro file. This should then look like this:

# Project identifier and version
# More information: https://felgo.com/doc/felgo-publishing/#project-configuration
PRODUCT_IDENTIFIER = net.vplay.demos.basicapp
PRODUCT_VERSION_NAME = 1.0.0
PRODUCT_VERSION_CODE = 1

# Optionally set a license key that is used instead of the license key from
# main.qml file (App::licenseKey for your app or GameWindow::licenseKey for your game)
# Only used for local builds and Felgo Cloud Builds (https://felgo.com/cloud-builds)
# Not used if using Felgo Live
PRODUCT_LICENSE_KEY = ""

# If you use plugins, move the property from the ios block to the root level instead, like this:
FELGO_PLUGINS += facebook

The main.cpp file needs a minor addition. Add this code right after the felgo.initialize(&engine) statement:

// Set an optional license key from project file
// This does not work if using Felgo Live, only for Felgo Cloud Builds and local builds
felgo.setLicenseKey(PRODUCT_LICENSE_KEY);

The build.grade file needs to include the following block, as child of the “android” item:

defaultConfig {
    applicationId = productIdentifier
    versionCode = productVersionCode.toInteger()
    versionName = productVersionName
}

The Project-Info.plist file needs to use placeholders, to apply the values defined in the *.pro file. Search for the following keys and add the placeholders:

<key>CFBundleExecutable</key>
<string>${EXECUTABLE_NAME}</string>
<key>CFBundleIdentifier</key>
<string>$(PRODUCT_BUNDLE_IDENTIFIER)</string>
<key>CFBundleName</key>
<string>${PRODUCT_NAME}</string>
<key>CFBundleShortVersionString</key>
<string>${PRODUCT_VERSION_NAME}</string>
<key>CFBundleVersion</key>
<string>${PRODUCT_VERSION_CODE}</string>

 

Benefits of Using Cloud Builds

There are a number of benefits in using a CI/CD for developing your projects. First of all, the obvious one, time savings:

  • No setup of native frameworks required
  • Cut time to provide new test versions
  • Cut time for publishing new versions
  • Release more frequent updates for your users

Apart from that, there are several other advantages that you can benefit from:

  • Easy integration with Git
  • Automatic upload to iOS TestFlight and Google Play testing tracks
  • Deploy to iOS without the need for a Mac
  • Soon you will also be able to select different Felgo and Qt versions to build with

Specifically for the build and deploy process of the new Android 64-bit architecture, you also gain the following benefits:

  • Store your signing information persistent. With Qt Creator, you will have to re-add them every time you close your project.
  • Build the app for both 32-bit and 64-bit architectures simultaneously.
  • Increment the version code for each build automatically.
  • Generate new license keys for each build version automatically.
  • Upload the generated APKs to the store, so you can access them from your Artifact Library.

 

 

This might also be interesting for you

Continuous Integration and Delivery (CI/CD) for Qt and Felgo

QML Tutorial: How to Create Native Cross Platform Apps with Qt and Felgo | Free Udemy Course

udemy-qml-tutorial-teaser

Release 3.2.0: Update to Qt 5.12.3 with ECMAScript 7, Subscriptions, Image Picker and Qt Creator 4.8.2

Release-3-2-0-Qt-5123-EcmaScript7-QtCreator-482

The post Android 64-Bit Support with Qt and Felgo Cloud Builds appeared first on Felgo.

GammaRay 2.11.0 Release

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

GammaRay 2.11 comes with a new inspection tool for Qt’s event handling, providing even more insights into the inner working of your application. Besides looking at the events and their properties as they occur the event monitor visualizes event propagation as it happens for Qt Quick or Qt Widgets input handling.

GammaRay event monitor log view GammaRay event monitor log view

Additionally the event monitor provides statistics on how often which type of event occurred, as well as fine-grained filtering options to find the events interesting for you even in a huge dataset.

GammaRay event monitor type view GammaRay event type view

Another major new feature is the network operation inspector. This allows you to observe the HTTP operations triggered via QNetworkAccessManager and helps to optimize network interactions, identify leaked QNetworkReply objects and ensure that all operations are encrypted.

GammaRay network operations view GammaRay network operation inspector

Next to this, GammaRay 2.11 got support for more data types (such as the QJson* classes), a new thread affinity checker for the problem reporter, and of course compatibility with the just released Qt 5.13. Behind the scenes we also did some work on performance, improving the responsiveness on large and/or busy inspected applications.

GammaRay 2.11 is available as part of the just released Qt Automotive Suite 5.13 including QtCreator integration and professional support, or GPL-licensed on Github.

About KDAB

KDAB is a consulting company offering a wide variety of expert services in Qt, C++ and 3D/OpenGL and providing training courses in:

KDAB believes that it is critical for our business to contribute to the Qt framework and C++ thinking, to keep pushing these technologies forward to ensure they remain competitive.

The post GammaRay 2.11.0 Release appeared first on KDAB.

[Update] Faster link time for Qt WebAssembly

The guys working on Emscripten have begun integrating the new llvm wasm backend into mainstream emscripten. Although it is still not the default, it is now heaps easier to install and use, as you no longer need to build llvm yourself.

https://v8.dev/blog/emscripten-llvm-wasm

The jist of it is:

emsdk install latest-upstream
emsdk activate latest-upstream

According to the linked blog, there are code size benefits as well as link time speed-ups.

The faster link time mostly affects application builds.

Of course, you will need to recompile Qt for WebAssembly to use this, and need to configure it with the Qt WebAssembly specific option:

-device-option WASM_OBJECT_FILES=1

After that, you just need to run qmake as normal.

One note: You will need to remove the line

 -s \"BINARYEN_TRAP_MODE=\'clamp\'\"


from the mkspecs/wasm-emscripten/qmake.conf, as upstream llvm webassembly backend does it's own overflow clamping and does not support BINARYEN_TRAP_MODE argument.





Cutelyst 2.8.0 released

Cutelyst a Qt/C++ Web framework got a new release!

This release took a while to be out because I wanted to fix some important stuff, but time is short, I've been working on polishing my UPnpQt library and on a yet to be released FirebaseQt and FirebaseQtAdmin (that's been used on a mobile app and REST/WebApp used with Cutelyst), the latter is working quite well although it depends ATM on a Python script to get the Google token, luckly it's a temporary waste of 25MB of RAM each 45 minutes.

Back to the release, thanks to Alexander Yudaev it has cpack support now and 顏子鳴 also fixed some bugs and added a deflate feature to RenderView, FastCGI and H2.

I'm also very happy we now have more than 500 stars on GitHub :)

Have fun https://github.com/cutelyst/cutelyst/releases/tag/v2.8.0