Qt 5

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

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 ... [More] 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: 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:   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 Release 3.2.0: Update to Qt 5.12.3 with ECMAScript 7, Subscriptions, Image Picker and Qt Creator 4.8.2 The post Android 64-Bit Support with Qt and Felgo Cloud Builds appeared first on Felgo. [Less]

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 ... [More] 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 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 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 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: Qt, QML and Qt 3D OpenGL C++11/C++14/C++17 Debugging and Profiling 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. [Less]

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

We are happy to announce the release of Qt Creator 4.9.2! This release fixes some smaller bugs. Please find the details in our change log. Get Qt Creator 4.9.2 The opensource version is available on the Qt download page under “Qt Creator”, and you ... [More] find commercially licensed packages on the Qt Account Portal. Qt Creator 4.9.2 is also available as an update in the online installer. Please post issues in our bug tracker. You can also find us on IRC on #qt-creator on chat.freenode.net, and on the Qt Creator mailing list. The post Qt Creator 4.9.2 released appeared first on Qt Blog. [Less]

We are happy to announce the release of Qt Creator 4.10 Beta2 ! Most notably we fixed a regression in the signing options for iOS devices, and that the “Build Android APK” step from existing Android projects was not restored. As always you find more ... [More] details in our change log. Get Qt Creator 4.10 Beta2 The opensource version is available on the Qt download page under “Pre-releases”, and you find commercially licensed packages on the Qt Account Portal. Qt Creator 4.10 Beta2 is also available under Preview > Qt Creator 4.10.0-beta2 in the online installer. Please post issues in our bug tracker. You can also find us on IRC on #qt-creator on chat.freenode.net, and on the Qt Creator mailing list. The post Qt Creator 4.10 Beta2 released appeared first on Qt Blog. [Less]

We’re elated to announce the latest edition of our Qt Automotive Suite 5.13, a unified HMI toolchain and framework for building the next generation of digital cockpits. Three years ago, we introduced the Qt Automotive Suite to solve key challenges in ... [More] creating HMIs for digital cockpits in automobiles [1][2][3]. Qt Automotive Suite offers a unique end-to-end HMI solution with a single technology: combining world class tooling and automotive-specific software HMI components, with Qt optimized for embedded devices, In this release, we focused on a few selected areas to improve and expand the offering. In the market, we continue to see steady adoption of our technology by top OEMs and Tier 1 suppliers around the world. We will see volume production of vehicles powered by the Qt Automotive Suite rolling out as early as 2020. The Base Qt Automotive Suite 5.13 is based on the new Qt 5.13 and sits on top of its embedded offering – Qt for Device Creation. Qt 5.13 brings new features, updates, bug fixes, and other improvements. For more information, refer to the official release announcement at: https://blog.qt.io/blog/2019/06/19/qt-5-13-released/. We have also improved the tooling to make designing, developing, and deploying software with Qt more efficient for designers and developers. One such improvement is via Qt 3D Studio. With the version 2.4 release, Qt 3D Studio and its runtime is another component for the Qt Automotive Suite. Here’s an example of a full 3D Instrument Cluster to show you what’s possible with Qt 3D Studio: Instrument cluster built with Qt 3D Studio by Siili Solution (For more details, see https://www.behance.net/gallery/66707281/QT-Altair) The Components Our Reference UI, Neptune 3 UI, can now use Qt 3D Studio and its runtime to render 3D content. It’s also possible to switch between the new implementation based on the Qt 3D Studio Runtime and the previously available implementation based on Qt3D, which is still the default selection. This new scene loads assets directly from a Qt 3D Studio project, simplifying the task of incorporating changes from designers. The implementation still supports the existing “remote control” features to move some objects in the 3D scene with simple QML statements. We use this type of feature to control car doors, sunroof, and the trunk of our 3D car model. Additionally, all of the APIs for the UI have been retained. We optimized the 3D car model itself to improve its loading time. It’s possible to switch between three levels of complexity in the model, for optimal use of hardware capabilities. The UI controls for all these new switches are provided in the new “3D options” panel, in the Vehicle app. And we’re still not done with 3D just yet! In addition to the existing 2G gauges, the Neptune 3 UI cluster can now use the Qt 3D Studio runtime as well, with its own Qt 3D Studio-designed content. You can also switch between the 2D and 3D implementation. The new 3D gauges and 3D car model follow the color accent set in the General Settings. 3D runtime options between Qt 3D and Qt 3D Studio All applications follow the color theme managed by System UI The cluster UI now integrates with Qt Safe Renderer. This integration is focused on the development aspects, hence we have added some “tricks” to improve the developer productivity in these use cases – even using standard hardware, that typically doesn’t provide safe rendering. On the desktop, we use a separate application with its own top-level window that renders content using Qt Safe Renderer. This window is placed underneath the cluster window. If the Neptune 3 UI process stops or crashes, this Qt Safe Renderer window remains on the desktop and keeps rendering, fetching the values from the new Vehicle Data service. On embedded targets, we have a separate process that takes over the rendering if Neptune 3 UI, as the main UI, stops working. This implementation leverages all parts of the Qt Safe Renderer 1.1. We promote development of automotive and embedded HMI in separate apps running as multiple processes. In this release, we improved the application installation in Neptune 3 UI. It now uses a new configuration as the applications are not saved in the temporary folder anymore. In the System Dialog, the application control has been extended to provide controls and settings for life cycle states. It’s now possible to define which applications should be launched automatically on startup and which ones should be relaunched if they stop, in the event of a crash. System UI Apps configuration If you look at the list of applications, you may notice that most of Neptune 3 UI now consist of separate applications. You can stop all of them, if necessary. Most importantly, this improvement makes it possible for you to develop and test each part separately and independently; even across different teams. In our previous release, we introduced the UI harness, whereas with this release, Neptune 3 UI introduces new wrappers that allow developers to run these harnesses directly from Qt Creator; but you can also run these wrappers independently. There are two harnesses provided for reference: a cluster harness and a vehicle harness. If you run the cluster harness, it starts the cluster independently in QML Live, depending on whether QML live is available or not. Otherwise, the cluster runs with “qmlscene”. The harness is a key differentiator as it illustrates how our architecture allows part of Neptune 3 UI to be decomposed and run separately, using the same code base as when it runs completely. We mentioned the new Vehicle Data service above. In this release, we introduced it an additional out-of-process service, based on our old Remote Settings Server. This is a key improvement in the middleware infrastructure, which is now more tailored to the use of out-of-process services. While Neptune 3 UI runs, the values displayed in the cluster are simulated to change on their own. This is a nifty feature for demos, but is also very useful in day-to-day development. It helps HMI developers test the implementation in various states of the business logic. The simulation is powered by the Simulation Engine introduced in the last release, as part of Qt IVI. Just like the Neptune 3 UI, this simulation is written in QML. In this architecture, the Vehicle Data service is actually a fully autogenerated simulation server, that feeds data to the HMI via the same API as a real middleware service. The QML code running this simulation can model the business logic of many real life use cases. This is beneficial for HMI development, particularly in the early prototyping phase and other development phases. The Simulation Engine in Qt IVI has also been extended to support the new middleware infrastructure. This includes the use of Qt Remote Objects as a transport layer. In combination with the auto-generated code, the new middleware infrastructure provides a complete environment for HMI development separated from the middleware development. Improvements in the middleware infrastructure also include a revamped Companion app. Initially developed for testing, it’s now provided with Neptune 3 UI as a new app. This app implements a popular automotive use case: an in-vehicle companion app that runs on a mobile device and directly connects to the head unit. The app has an improved UI which is closer to real-world use cases. Companion mobile app The Companion app uses the same API for middleware as Neptune 3 UI itself. Both the API and backend plugins are shared, which saves both time and effort. Last, but not least, Neptune 3 UI now uses Qt Application Manager’s Intent Management, introduced in the last release. This feature is used to switch between the music sources: the Tuner and the Media Player. The Tools We have released version 2.11.0 of GammaRay; our Qt application monitoring tool. GammaRay allows you to observe the behavior and data structures of Qt code inside your program live at runtime. GammaRay 2.11.0 includes a new inspection tool for Qt’s event handling, providing deeper insights into the inner workings of your application. Apart from analyzing the events and their properties as they occur, the event monitor visualizes event propagation during input handling, as it happens for both Qt Quick or Qt Widgets. Additionally, the event monitor now provides statistics on how often which type of event occurred, as well as fine-grained filtering options to drilldown into events that may interest you , even in a huge dataset. One major new feature is the network operation inspector, that allows you to observe the HTTP operations triggered via QNetworkAccessManager and helps you to optimize network interactions, identify QNetworkReply objects that may have leaked, and ensure that all operations are encrypted. GammaRay 2.11.0 now supports more data types, like the QJson* classes, a new thread affinity checker for the problem reporter, as well as compatibility with the newly released Qt 5.13. Under the hood, we’ve also done some performance improvements, particularly improving GammaRay’s responsiveness when inspecting large and/or busy applications. QML Live is both, a local and a remote Qt Quick live reloading system that allows you to change your QML UI source code and view the result in real time. QML Live in action In this release, QML Live supports multi-process rendering. This is a substantial change, that lets you start multiple runtimes to observe changes in more than one top-level HMI view. We have also resumed active development of the Qt Creator plugin for Qt Application Manager. In addition to the internal improvements, the plugin now has a simplified UI and a bit more automation, to reduce the number of configuration steps. Documentation In this release, we‘ve invested significant effort into improving and rewriting large parts of our documentation. We’ve tried to focus on explaining the key concepts and approaches that we use, with the hope that this content fills in the gaps and aids new users to connect the dots: https://doc.qt.io/QtAutomotiveSuite/index.html. Looking Ahead We are looking to add hardware cursor key navigation, provide a basic support for voice assistants, support background application services, bundle packages, integrate the Deployment Server into the workflow in Qt Creator, and also automatically populate the Deployment Server with apps from a specific repository. Furthermore, we continue to improve support for multi-domain architecture on a single SoC, embracing webOS, Android Automotive OS, AGL, GENIVI and bringing inter-domain interactivity on top Digital cockpit by Siili Solution (https://www.behance.net/gallery/79438455/Enhancing-the-driving-experience) Summary With Qt Automotive Suite 5.13, we’ve made more steps towards our goal: unleash the power of Qt to make the development of appealing UX easy and fast. We want to help our customers to transform their visions and concepts into HMIs that you can experience at car dealerships near you. One of these days you might see the next version of this appealing prototype made with Qt: Peugeot E-Legend digital cockpit (https://www.peugeot.co.uk/concept-cars/e-legend/) Finally, big thanks for our partners, KDAB and Luxoft, for the great collaborative work and contributions. We are also very grateful to our customers and prospects for their continuous feedback and open discussions. If you have questions about Qt Automotive Suite, fell free to contact us. The post Announcing the Qt Automotive Suite 5.13 appeared first on Qt Blog. [Less]