We are very happy to announce an updated version of the Qt Automotive Suite, a unified HMI toolchain and framework for digital cockpit, is now available.

In case you hear about this for the first time, Qt Automotive Suite was created together with KDAB and Luxoft to solve the key challenges in HMI creation for digital cockpits in automobiles. With combinations of world class tooling, automotive specific software components, and highly optimized software framework for embedded devices, we are solving those challenges and offering the world’s end-to-end HMI solution with a single technology.

In Qt Automotive Suite 5.11 we have a major upgrade for the 3D tooling, complete overhaul of our reference UI and improvements on automotive components. All of these are built on top of Qt 5.11 series, bringing the cutting edge of what Qt Automotive Suite offers.

Faster, better, stronger

For those of you who are already familiar with Qt Automotive Suite releases, you might have noticed immediately that we no longer maintain its own version number. Good catch! Since the release of Qt Automotive Suite 2.0 this year, we decided to make new releases following Qt’s release schedule. That way, every Qt Automotive Suite future release can benefit new features and improvements from each Qt release, and more importantly we can now make new releases more frequent.

With mere four months time between Automotive Suite 2.0 and 5.11 releases, we are very pleased to see more OEMs and Tier1s took interest, and quite a few of them adopted it for developing their next generation digital cockpit platforms. Once again proving that OEMs and Tier1s would like to consolidate into one technology for the entire digital cockpit HMI development.

What’s new?

So, what is in Qt Automotive Suite 5.11? The most visible part of the new release is the new reference UI. The reference UI is not a showcase for the capabilities but actually a starting point for iterative development either in the UI or underlying functionality.

Figure 1. Neptune Reference UI

Qt Automotive Suite 5.11 comes with a major overhaul of Neptune Reference UI and a new User Experience design. There are now three parts in this Reference UI: an instrument cluster, an IVI, and a mobile app for remote control. It forms the minimum building blocks for the digital cockpit HMI where the instrument cluster is for the driver, in-vehicle infotainment is for the driver or passenger, and a mobile app that the driver or passenger can custom their favorite settings remotely.

So how Automotive Suite was used to build the Neptune UI? You will find more detail in the “Neptune Reference UI in depth” section. Let’s look at Automotive Suite architecture.

Figure 2. Qt Automotive Suite Architecture

In summary, the above diagram reflects our vision to provide easy-to-use tools that free designers and software engineers to rapidly create superior digital cockpits.

Qt for Device Creation 5.11

Of course, Qt Automotive Suite 5.11 sits on top of Qt 5.11, bringing major performance improvement and new feature set.

Qt 3D Studio 2.0

We believe a truly unified HMI toolchain and framework should also ship with advanced UI authoring tool for the designers. With 3D becoming a more significant part of the HMI we saw the need for a design tool that facilitates rapid 3D UI/UX concepting and design. With Qt 3D Studio 2.0, we have now all new 3D rendering engine and a great number of improvement on the usability and features. Have a read at Qt 3D Studio 2.0 blog.

Check out our latest cluster demo (codename Altair) implemented by 3D Studio 2.0.

Qt Safe Renderer 1.0

Functional safety is a critical path that our customers must cross. Qt Automotive Suite 5.11 includes the Qt Safe Renderer, which is now certified by ISO 26262 part 6 up to ASIL-D specification. If you missed the announcement, be sure to check out here.

Qt Application Manager

Qt Application Manager brings a modern multi-process GUI architecture to the IVI. By separating the HMI into different functional units (for example, HVAC could be one unit while Navigation could be another), Qt Application Manager enables independent teams to develop and test both separately and simultaneously, thereby reducing project risk and shortening development time. In addition, splitting the UI into smaller applications also makes it easier to do system updates; smaller pieces of code are touched, and the OTA updates are smaller. To learn about Qt Application Manager, check out the documentation at: https://doc.qt.io/QtApplicationManager/index.html

With Qt Automotive Suite 5.11, Application Manager has received updates highlighted as follow:

• Improved performance monitoring and profiling API that now supports GPU utilization.
• QtObject can be the root element of an app or a System UI, thus improving the multi-window support.
• We’ve also added support of OpenSSL 1.1 as required in Qt 5.11
• There is now support for extra meta-data in application packages, which enables new features in future releases of the Deployment Server (previously known as “App Store Server”).

Qt Application Manager Plugin for Qt Creator

Since Qt Application Manager controls the application lifecycle, a direct launching from Qt Creator is not possible. A special plugin is provided now which wraps the command line tools provided in Qt Application Manager and integrates all essential steps into Qt Creator IDE. In Qt Automotive Suite 5.11, we have improved our documentation and the plugin stability.

Qt IVI

To tackle reusability, QtIVI brings a level of standardization within the Qt ecosystem for how to access and extend automotive-specific APIs. The applications developed in one generation of a program can be reused on the next, even if the underlying platform is different. This is particularly important as OEMs are increasingly taking control of the car HMI development, reducing duplication of work means significant cost saving and more focus on brand UX differentiation. Qt Automotive Suite is designed to integrate well with industry’s leading initiatives such as GENIVI and AGL, further increasing the reusability on the platform level for the entire industry. More detail can be found here.

With Qt Automotive Suite 5.11, Qt IVI has received updates highlighted as follow:

• In Qt Automotive Suite 2.0, we introduced the use of IVI APIs auto-generated from IDL files written in QFace. In 5.11, it also can also use QtRemoteObjects as an IPC provider. The latter allows further modularization of the IVI middleware across multiple processes with clear benefits in stability and a cleaner architecture.
• To make it easier to write and maintain the templates for the “ivigenerator”, a common template folder has been introduced. With this change we also introduced common Jinja macros, which removes a lot of common boiler-plate code in our macros.
• The “ivigenerator” now also supports additional annotation files. This can be useful if multiple parts are generated from the same QFace file, whereas every project needs different annotations.
• A new “QIviPendingReply” class was introduced. This class is a QFuture/Promise like API which can be used from C++ as well as from QML and is used to provide the return value of a function in an asynchronous manner. This is already fully integrated into the new QtRemoteObject based generator templates.

Comprehensive documentation

Without exception, we continuously improve our documentation. Qt Automotive Suite 5.11 comes with more comprehensive documentation and examples for most of development needs.

Summary

With Qt Automotive Suite 5.11, we have further strengthened our offering for the truly end-to-end solution for the digital cockpit HMI development. We brought in all new Qt 3D Studio 2.0 with many of the needed changes for automotive HMI designers, we added the fully certified Qt Safe Renderer for addressing the functional safety. We revamped the Neptune Reference UI that provides modern reference to digital cockpit design, and showcased how easy is to build digital cockpit with Qt Automotive Suit. We made significant number of improvements on all our software components. Finally, many thanks for the feedback especially from our customers and prospects.

Neptune Reference UI in depth

IVI

To highlight the multi-process UI capability of our Qt Application Manager, we redesigned the System UI with a strong focus on what’s possible with multi-process UI paradigm

Figure 3. Neptune IVI with focus on multi-process UI

As depicted by the figure above, we now introduced a new concept of “App Widgets” shown on the System UI, while each app widget runs in its own process implemented in Qt Application Manager. User can freely move each app up and down, open or close the app. When you resize the app window, the app will automatically display the right content based on window size, thus addressing the popular trend called Response UI.

We have added theming and accent color to the IVI settings, so a user can select dark and light theme with multiple accent colors, thus provides reference to how Qt Automotive Suite enables theming capability.

Figure 4. Theming and color accent

For navigation and mapping, we now leverage the Qt Location Mapbox GL Plugin, which provides the Mapbox mapping and styling by following Neptune UI theme and styles.

Figure 5. Mapbox GL plugin from Qt Location

The Vehicle application now contains an interactive 3D car model and adds controls visualizing user actions via manipulations of 3D objects via QML API. All this is completely based on Qt3D and so demonstrates that no additional software is required to visualize 3D objects in automotive use cases.

Figure 6. 3D car model and seamless integration with QML control

Instrument cluster

On the instrument cluster side, user can now share the content shown on the IVI onto the instrument cluster screen. Also, Qt Safe Renderer has been used to render the tell-tales as separate process via RTOS and hypervisor.

Figure 7. instrument cluster gets the Mapbox view shared by IVI

Inter-domain and inter-process communication

To cater the need for inter-process and inter-domain communication, we implemented a new Remote Settings Server based on Qt Remote Objects, which can serve multiple clients running on the same host or remote instances. For example, our new mobile app called “NeptuneControlApp” is capable of running on a mobile device. The app can communicate to the Remote Settings Server, and user can for instance change the language of the digital cockpit as well as many other settings that are accessible. Perhaps the best part of the app is that it shares the auto-generated code base with Neptune UI and the Setting Server, thus matching to exposed setting options without manual work.

Figure 8. Remote Control App for Android and iOS

Check out the documentation at: https://doc.qt.io/Neptune3UI/index.html.

The post Introducing Qt Automotive Suite 5.11 appeared first on Qt Blog.

Now that Qt 3D Studio 2.0 has been released, let’s look at what some of the new features enable. In particular, we will visit the so-called in-scene debug and profile views, as these handy, built-in (both to the viewer launched from the editor and, if the developer decides so, to applications) views allow answering questions like What happens between loading a scene and issuing OpenGL draw commands?, Is this 3D scene too heavy?, How much graphics resources does this scene use?, or Is there any chance this scene will perform on this or that embedded hardware?

Note that this post assumes a certain level of familiarity with the basic concepts of Qt 3D Studio. For an introduction, refer to the editor and runtime Getting Started pages of the documentation.

Firing up the viewer by clicking the green Play button in the toolbar of the Qt 3D Studio application launches q3dsviewer, which is a simple Qt application that uses the Qt 3D Studio Runtime to load and render the presentation into a QWindow. With 2.0 and its migration to a new engine that is using Qt 3D internally, the viewer now offers a menu item View/Profile and Debug (or just press F10). We will use the viewer in the following examples but it is worth remembering that all this is available to any application using the runtime.

First, we have some quite standard information up there: (note that everything is live and updated every frame)

• OpenGL – useful on some platforms to verify the application is indeed running against the desired implementation, or to see if the runtime is using its OpenGL ES 2.0 level reduced functionality mode (see the System Requirements page in the documentation for more in this).
• CPU and memory usage (available on Windows and Linux (incl. Android))
• and of course, the frame rate (with a simple, configurable visualization even).

Given that this is built-in and is rendered in-scene (so works with platform plugins like eglfs as well), and so can be brought up on any embedded device, this view alone can be quite valuable during the development phase.

The rest is a bit more tricky since some of it may need some understanding of what happens under the hood. Some of you may remember a Qt World Summit talk from last year, discussing implementing a “runtime on top of Qt 3D”. This describes the concept well and is still valid today. In short, the Qt 3D Studio editor generates .uip (and .uia) files which are XML documents describing the scene and other things.

Excerpt from SampleProject’s .uip file

(click on the images for a full size view!)

Now, before anyone gets a shock from all that XML stuff, the good news it that this is basically irrelevant. The format may change arbitrarily in the future, and could be JSON, a binary blob, or QML even (hint hint…). It is just a serialization format in its current form. What matters is the scene (and slide) trees that are then created by the runtime when parsing this input. The concept is very similar to the scene graph of Qt Quick, where the QQuickItem tree is backed by a QSGNode tree. With Qt 3D Studio the QQuickItem tree has no equivalent (yet! (hint hint…)) and we are building up a Q3DSGraphObject tree either by parsing the XML document or programatically with a (currently private) C++ API.

SampleProject scene structure

The (experimental) console’s scenegraph command shows this very well. Bringing up the console from the Scene Info section and typing scenegraph prints the Q3DSGraphObject tree. Unsurprisingly, this matches almost completely the scene tree in the editor’s Timeline view.

Note that at this point we still have nothing to do with actual graphics resources, APIs like OpenGL, or drawing anything on screen. We could just have stopped here, manipulate our Q3DSGraphObject tree a bit, and then maybe serialize it back to a file, without ever initializing anything graphics related. Graphics only comes in the picture in the next step:

The generated Qt 3D entity graph(the Qt 3D entity graph viewer is not available in 2.0 but is already merged to the master branch and will therefore be place in 2.1 later this year)

For those who have experience with Qt 3D this probably is starting to look familiar.

Based on the Q3DSGraphObject tree, a Qt 3D framegraph and scene (entity) graph are generated and kept up-to-date in sync with any changes to the Qt 3D Studio data structures. It is then up to the Qt 3D renderer to manage graphics resources (textures, buffers) and generate draw calls based on the entity and framegraphs.

Model nodes become entities with one or more child entities (one for each sub-mesh) which have components like a material and a Q3DSMesh (a QGeometryRenderer subclass) on them, thus turning them into renderable entities. Each of these will lead to eventually issuing an OpenGL draw call (glDrawElements or similar).

The QLayer components show how the “tagging” to differentiate between the opaque and transparent (and sometimes other) passes is done in practice: the renderable entities (the ones with Q3DSMesh on them) only have one QLayer component associated since they belong either to the opaque or the transparent pass, but not both. The ancestors, like the parent “model” entity, or entities corresponding to group nodes have 2 QLayers since these are non-renderable (no draw call is generated for them) and their transform has to be taken into account in all passes.

Text is (for now) done by rendering into a QImage with the raster paint engine (QPainter) and then drawing a textured quad, as witnessed by the single entity generated for the DateAndTime text node.

This in itself does not tell much about the number or size of graphics resources. To help designers and developers getting an overview of the approximate graphics resource usage, the Qt 3D Studio runtime tracks some of the relevant Qt 3D objects it creates, in particular texture and buffer instances which under the hood lead to create OpenGL texture and buffer objects. This is what is shown in the Qt 3D Objects view:

Qt 3D object list

• Is the model the designer provided too complex? Seeing a lot of submeshes with lots of data in them should raise a flag right away. Such meshes may render just fine on a desktop PC but can cause performance issues on an embedded device.
• Are we wasting time on unnecessary blending? Blending means the object belongs to the transparent pass and so the mesh is rendered with together with the other “transparent” meshes with blending enabled, sorted back-to-front. This is unnecessary and wasteful if there is in fact no need for full or partial transparency.
• Are the texture maps too large? A quick look at the texture list can reveal another set of potential problems that may pop up when deploying to a more constrained target platform.
• Is multisample antialiasing in use? MSAA may make things look nice on the design PC but may be too much to ask from some of the typical embedded devices today.

Pay attention to the Shares data column. Two rows in the texture list does not mean there are two OpenGL textures active. For example, using the same file as the source of more than one texture map will often lead to reusing the same data and ending up with using the exact same OpenGL texture object under the hood.

Now that we have the data to render with (geometry, shaders, textures), what is left is to define how exactly the rendering is to be done. This is ensured by generating and maintaining a Qt 3D framegraph:

SampleProject Qt 3D framegraph

This framegraph view is likely not that essential for typical users. It is most useful to those who are looking for deeper understanding and to develop the runtime.

Note that Layer Caching option in the Alter Scene section on the left. (do not confuse Qt 3D Studio layers with Qt 3D QLayers: in Qt 3D Studio a scene consist of one or more layers, each of which acts as a mini-scene with its own 2D backing store (OpenGL texture in practice), which are then composed together with a simple (or sometimes not so simple) texture blit as the last step in the rendering process – this is no different than Qt Quick layers in fact. Qt3D’s QLayer has nothing to do with this and can rather be thought of as a tag that can be attached to entities to allow filtering them.)

When there is no change in a layer (nothing is animated), there is no need to re-render the contents of it for the next frame, the existing texture contents can be used for composition as-is. This is implemented by dynamically taking out/re-adding framegraph node subtrees from/to the framegraph. This is also reflected by the live framegraph view, so to get a full overview of what the rendering of the scene involves, turn Layer Caching off temporarily.

One may wonder why there are seemingly useless QFrameGraphNode objects with a sole QNoDraw child in the tree. The reason is that subtrees may be generated inserted dynamically upon certain conditions (say a light becomes shadow casting, SSAO gets enabled, progressive AA gets enabled for a layer, etc.), and these “dummy” nodes with their no-op child leaf are placeholders.

Enough of tree views, back to the simpler tables:

SampleProject layer list

The Layer list shows all the Qt 3D Studio layers. Each of these has one or more corresponding textures in the Qt 3D Objects view. Watch out for things like:

• Are the antialiasing settings sane? See this documentation page for an overview of the available AA techniques. All of them come at a cost when it comes to performance and resource usage.
• Are the Dirty and Cached values as expected? Layers that have no animations running in them are expected to be in Dirty == false and Cached == true state (thus avoiding re-rendering the contents every frame).
• If an advanced blend mode (overlay, color burn, color dodge) is used, make sure it is really required as these involve additional resources and expensive extra blits.

Note the Presentation combo box that is present in this and many other views. Qt 3D Studio allows using multiple sub-presentations, as explained here. The contents of sub-presentations are rendered into textures which are then used either as the contents of some layer in the main presentation, or as texture maps for some material. As the main and the sub-presentations each have their own Q3DSGraphObject tree, most related functionality in the console and in the debug views is organized on a per-presentation basis. Use the combo box or the appropriate console command to switch between the presentations.

Finally, note that there is extensive qDebug output from the runtime. The debug messages are also collected and shown in the Log view. This allows easy filtering, allowing turning off uninteresting messages. The most interesting categories are q3ds.perf, q3ds.scene, and q3ds.uip.

q3ds.perf log messages

Certain operations that are considered especially heavy will trigger a q3ds.perf message. This can be helpful to recognize some less optimal design choices in the presentations.

The post What’s in a Qt 3D Studio Scene? appeared first on Qt Blog.

There has been a lot of back and forth around the use of Free Software in public administration. One of the latest initiatives in this area was started by the Free Software Foundation Europe, FSFE. It focuses on the slogan: Public Money – Public Code. There are various usage scenarios for Free Software in public administration. The span ranges from the use of backend technology over user-facing software, e.g. LibreOffice, up to providing a whole free desktop for the administrative staff in a public service entity such as a city council. In this article we will focus on the latter.

When the desktops in an administration are migrated to Linux, the administration becomes a distribution provider. An example for this is the LiMux desktop, that powers the administration of the city of Munich since 2012.

LiMux is a distribution, maintained by the central IT department of the City of Munich. Technically, it builds upon Kubuntu. It provides specific patches, a modified user experience and an automatic distribution system, so all desktops in all departments of the city can be easily administered and offer a consistent user experience.

Distributions in the Free Software ecosystem have different roles, one of them surely being the provider of the finishing touches, especially to important software for its own users. Obviously public administration has special demands. Workflows and documents for example have a totally different importance than for the average Kubuntu user.

In Munich for example, architects in one department complained that Okular, the LiMux and KDE pdf reader, would freeze when they tried to open large construction plans. When the city investigated this issue further, they found out that actually Okular wouldn’t freeze, but loading these large maps would simply occupy Okular for quite a while, making the user think it crashed.

Naturally the City of Munich wanted this issue fixed. But this use case is rather rare for the voluntary Free Software Developer, as only few user groups, like architects, are actually in the situation of having to deal with such large files, so it was unlikely that this bug would be fixed on a voluntary basis.

Since the city does not have enough developer power to fix all such issues themselves, they looked to KDAB for external support. With our KDE and Qt expertise, we were well-positioned to help. Together we identified that, instead of the suggested busy indicator for Okular the City of Munich wanted, progressive loading would be an even better solution. It allows the user to visually follow the loading process and makes it possible for the user to interact with large files as early as possible. And as the City does not want to maintain a patch that fixes this issue for them locally, we also helped them to get all the patches upstream.

This way all efforts are made available for the architects at the City of Munich and also for the general public. In the same spirit we have fixed numerous issues for the City of Munich all around KDE and Qt. As another example: we brought back extended settings to the Qt print dialogue. This allows the City of Munich to make use of all of the functionalities of their high-tech printer, like sorting, stapling and so on. You can read more about KDAB’s work on this here.

Becoming a distribution implies a lot of responsibility for a public administration and KDAB is proud to offer reliable backup for any administration that decides to follow the Linux, Qt and KDE path.

Afternote: Recent developments mean that the City has decided to revert the migration back to Microsoft by 2020. The good news is that most changes and adjustments they have made are available upstream and other administrations can build their own solutions upon them.

The post The LiMux desktop and the City of Munich appeared first on KDAB.

KDAB was sponsor of this annual C++ event run by the C++ Community for the C++ Community in Italy, which was founded some five years ago and is growing fast.

Around 200 people showed up for “++ it”, 50 more than last year, and were treated to an excellent program. There was a mix of talks in either English or Italian, including ‘Debug C++ Without Running‘ by Anastasia Kazakova, ‘C++ Barbarian Quiz & Introduction to Conan C/C++ Package Manager‘ from Diego Rodriguez-Losada Gonzalez and one from Vittorio Romeo on ‘Zero-allocation & no type erasure futures‘, all of which KDAB particularly enjoyed.

You can see the full program and a post-event report here.

The post KDAB at Italian C++, Milan appeared first on KDAB.

Thanks for joining us for this year’s edition of Meet Qt that took place in Paris on the 19th June.

The focus this year was medical and automotive and the event was again very successful despite the train strikes. If you could not attend here is an idea of what KDAB offered:

A medical client’s showcase presentation – Qi Tissue using Qt 3D and taking the hunt for a cure for cancer to new levels.

Learn more about this project and watch the video…

Download the presentation slides…

For automotive needs, Qt Automotive Suite attached to GammaRay directly via Qt Creator provides a comprehensive package, including the powerful Qt 3D framework.

Watch the video…

Qt Quick Software Renderer provides a fluid 60fps touch UI and H.264 video decoding on hardware with no GPU or hardware video decoding acceleration, with the full feature set of Qt and with as little as 64MB of RAM and/or Flash memory.

Find out more and see the video…

The post KDAB at Meet Qt in Paris appeared first on KDAB.

In our first part of this series, we looked at how to set up messages, combine them, and reduce their overhead in the context of telemetry sensors.

This part focuses on the payload of messages and how to optimize them.

There are multiple methods to serialize an object with Qt. In part one, we used JSON. For this, all sensor information is stored in a QJsonObject and a QJsonDocument takes care to stream values into a QByteArray.

QJsonObject jobject;

jobject["SensorID"] = m_id;

jobject["AmbientTemperature"] = m_ambientTemperature;

jobject["ObjectTemperature"] = m_objectTemperature;

jobject["AccelerometerX"] = m_accelerometerX;

jobject["AccelerometerY"] = m_accelerometerY;

jobject["AccelerometerZ"] = m_accelerometerZ;

jobject["Altitude"] = m_altitude;

jobject["Light"] = m_light;

jobject["Humidity"] = m_humidity;

QJsonDocument doc( jobject );

 

return doc.toJson();

JSON has several advantages:

• Textual JSON is declarative, which makes it readable to humans
• The information is structured
• Exchanging generic information is easy
• JSON allows extending messages with additional values
• Many solutions exist to receive and parse JSON in cloud-based solutions

However, there are some limitations to this approach. First, creating a JSON message can be a heavy operation taking many cycles. The benchmark in part 2 of our examples repository highlights that serializing and de-serializing 10.000 messages takes around 263 ms. That might not read like a significant number per message, but in this context time equals energy. This can significantly impact a sensor which is designed to run for years without being charged.

Another aspect is that the payload for an MQTT message per sensor update is 346 bytes. Given that the sensor sends just eight doubles and one capped string, this can be a potentially huge overhead.

Inside the comments of my previous post, using QJsonDocument::Compact has been recommended, which reduces the payload size to 290 bytes in average.

So, how can we improve on this?

Remember I was referring to textual JSON before? As most of you know, there is also binary JSON, which might reduce readability, but all other aspects are still relevant. Most importantly, from our benchmarks we can see that a simple switch of doc.toJson() to doc.toBinaryData() will double the speed of the test, reducing the iteration of the benchmark to 125msecs.

Checking on the payload, the message size is now at 338 bytes, the difference is almost neglectable. However, this might change in different scenarios, for instance, if you add more strings inside a message.

Depending on the requirements and whether third-party solutions can be added to the project, other options are available.

In case the project resides “within the Qt world” and the whole flow of data is determined and not about to change, QDataStream is a viable option.

Adding support for this in the SensorInformation class requires two additional operators

QDataStream &operator<<(QDataStream &, const SensorInformation &);
QDataStream &operator>>(QDataStream &, SensorInformation &);

The implementation is straightforward as well. Below it is shown for the serialization:

QDataStream &operator<<(QDataStream &out, const SensorInformation &item)
{
    QDataStream::FloatingPointPrecision prev = out.floatingPointPrecision();
    out.setFloatingPointPrecision(QDataStream::DoublePrecision);
    out << item.m_id
        << item.m_ambientTemperature
        << item.m_objectTemperature
        << item.m_accelerometerX
        << item.m_accelerometerY
        << item.m_accelerometerZ
        << item.m_altitude
        << item.m_light
        << item.m_humidity;
    out.setFloatingPointPrecision(prev);
    return out;}

Consulting the benchmarks, using QDataStream resulted in only 26 msecs for this test case, which is close to 10 times faster to textual JSON. Furthermore, the average message size is only 84 bytes, compared to 290. Hence, if above limitations are acceptable, QDataStream is certainly a viable option.

If the project lets you add in further third-party components, one of the most prominent serialization solutions is Google’s Protocol Buffers (protobuf).

To add protobuf to our solution a couple of changes need to be done. First, protobuf uses an IDL to describe the structures of data or messages. The SensorInformation design is

syntax = "proto2";

package serialtest;

message Sensor {
    required string id = 1;
    required double ambientTemperature = 2;
    required double objectTemperature = 3;
    required double accelerometerX = 4;
    required double accelerometerY = 5;
    required double accelerometerZ = 6;
    required double altitude = 7;
    required double light = 8;
    required double humidity = 9;
}

To add protobuf’s code generator (protoc) to a qmake project, you must add an extra compiler step similar to this:

PROTO_FILE = sensor.proto
protoc.output = $${OUT_PWD}/${QMAKE_FILE_IN_BASE}.pb.cc
protoc.commands = $${PROTO_PATH}/bin/protoc -I=$$relative_path($${PWD}, $${OUT_PWD}) --cpp_out=. ${QMAKE_FILE_NAME}
protoc.variable_out = GENERATED_SOURCES
protoc.input = PROTO_FILE
QMAKE_EXTRA_COMPILERS += protoc

Next, to have a comparable benchmark in terms of object size, the generated struct is used as a member for a SensorInformationProto class, which inherits QObject, just like for the QDataStream and JSON example.

class SensorInformationProto : public QObject
{
    Q_OBJECT
    Q_PROPERTY(double ambientTemperature READ ambientTemperature WRITE setAmbientTemperature NOTIFY ambientTemperatureChanged)
[...]

public:
    SensorInformationProto(const std::string &pr);
[...]

     std::string serialize() const;
 [...]

private:
    serialtest::Sensor m_protoInfo;
};

The serialization function of protoInfo is generated by protoc, so the step to create the payload to be transmitted looks like this:

std::string SensorInformationProto::serialize() const
{
    std::string res;
    m_protoInfo.SerializeToString(&res);
    return res;
}

Note that compared to the previous solutions, protobuf uses std::string. This means you are losing capabilities of QString, unless the string is stored as a byte array (manual conversion is required). Then again, this will slow down the whole process due to parsing.

From a performance perspective, the benchmarks results look promising. The 10.000 items benchmark only takes 5 ms, with an average message size of 82 bytes.

As a summary, the following table visualizes the various approaches:

One promising alternative is CBOR, which is currently getting implemented by Thiago Macieira for Qt 5.12. However, as development is in progress it has been too early to be included in this post. From discussions on our mailing list, results are looking promising though, with a significant performance advantage over JSON, but with all its benefits.

We have seen various approaches to serialize data into the payload of an MQTT message. Those can be done purely within Qt, or with external solutions (like protobuf). Integration of external solutions into Qt is easy.

As a final disclaimer, I would like to highlight that those benchmarks are all based on the scenario of the sensor demo. The amount of data values per message is fairly small. If those structs are bigger in size, the results might differ and different approaches might lead to the better results.

In our next installment, we will be looking at message integration with DDS. For an overview of all the articles in our automation mini-series, please check out Lars’ post.

The post Serialization in and with Qt appeared first on Qt Blog.

We are very happy to announce an updated version of the Qt Automotive Suite, a unified HMI toolchain and framework for digital cockpit, is now available.

In case you hear about this for the first time, Qt Automotive Suite was created together with KDAB and Luxoft to solve the key challenges in HMI creation for digital cockpits in automobiles. With combinations of world class tooling, automotive specific software components, and highly optimized software framework for embedded devices, we are solving those challenges and offering the world’s end-to-end HMI solution with a single technology.

In Qt Automotive Suite 5.11 we have a major upgrade for the 3D tooling, complete overhaul of our reference UI and improvements on automotive components. All of these are built on top of Qt 5.11 series, bringing the cutting edge of what Qt Automotive Suite offers.

Faster, better, stronger

For those of you who are already familiar with Qt Automotive Suite releases, you might have noticed immediately that we no longer maintain its own version number. Good catch! Since the release of Qt Automotive Suite 2.0 this year, we decided to make new releases following Qt’s release schedule. That way, every Qt Automotive Suite future release can benefit new features and improvements from each Qt release, and more importantly we can now make new releases more frequent.

With mere four months time between Automotive Suite 2.0 and 5.11 releases, we are very pleased to see more OEMs and Tier1s took interest, and quite a few of them adopted it for developing their next generation digital cockpit platforms. Once again proving that OEMs and Tier1s would like to consolidate into one technology for the entire digital cockpit HMI development.

What’s new?

So, what is in Qt Automotive Suite 5.11? The most visible part of the new release is the new reference UI. The reference UI is not a showcase for the capabilities but actually a starting point for iterative development either in the UI or underlying functionality.

Figure 1. Neptune Reference UI

Qt Automotive Suite 5.11 comes with a major overhaul of Neptune Reference UI and a new User Experience design. There are now three parts in this Reference UI: an instrument cluster, an IVI, and a mobile app for remote control. It forms the minimum building blocks for the digital cockpit HMI where the instrument cluster is for the driver, in-vehicle infotainment is for the driver or passenger, and a mobile app that the driver or passenger can custom their favorite settings remotely.

So how Automotive Suite was used to build the Neptune UI? You will find more detail in the “Neptune Reference UI in depth” section. Let’s look at Automotive Suite architecture.

Figure 2. Qt Automotive Suite Architecture

In summary, the above diagram reflects our vision to provide easy-to-use tools that free designers and software engineers to rapidly create superior digital cockpits.

Qt for Device Creation 5.11

Of course, Qt Automotive Suite 5.11 sits on top of Qt 5.11, bringing major performance improvement and new feature set.

Qt 3D Studio 2.0

We believe a truly unified HMI toolchain and framework should also ship with advanced UI authoring tool for the designers. With 3D becoming a more significant part of the HMI we saw the need for a design tool that facilitates rapid 3D UI/UX concepting and design. With Qt 3D Studio 2.0, we have now all new 3D rendering engine and a great number of improvement on the usability and features. Have a read at Qt 3D Studio 2.0 blog.

Check out our latest cluster demo (codename Altair) implemented by 3D Studio 2.0.

Qt Safe Renderer 1.0

Functional safety is a critical path that our customers must cross. Qt Automotive Suite 5.11 includes the Qt Safe Renderer, which is now certified by ISO 26262 part 6 up to ASIL-D specification. If you missed the announcement, be sure to check out here.

Qt Application Manager

Qt Application Manager brings a modern multi-process GUI architecture to the IVI. By separating the HMI into different functional units (for example, HVAC could be one unit while Navigation could be another), Qt Application Manager enables independent teams to develop and test both separately and simultaneously, thereby reducing project risk and shortening development time. In addition, splitting the UI into smaller applications also makes it easier to do system updates; smaller pieces of code are touched, and the OTA updates are smaller. To learn about Qt Application Manager, check out the documentation at: https://doc.qt.io/QtApplicationManager/index.html

With Qt Automotive Suite 5.11, Application Manager has received updates highlighted as follow:

• Improved performance monitoring and profiling API that now supports GPU utilization.
• QtObject can be the root element of an app or a System UI, thus improving the multi-window support.
• We’ve also added support of OpenSSL 1.1 as required in Qt 5.11
• There is now support for extra meta-data in application packages, which enables new features in future releases of the Deployment Server (previously known as “App Store Server”).

Qt Application Manager Plugin for Qt Creator

Since Qt Application Manager controls the application lifecycle, a direct launching from Qt Creator is not possible. A special plugin is provided now which wraps the command line tools provided in Qt Application Manager and integrates all essential steps into Qt Creator IDE. In Qt Automotive Suite 5.11, we have improved our documentation and the plugin stability.

Qt IVI

To tackle reusability, QtIVI brings a level of standardization within the Qt ecosystem for how to access and extend automotive-specific APIs. The applications developed in one generation of a program can be reused on the next, even if the underlying platform is different. This is particularly important as OEMs are increasingly taking control of the car HMI development, reducing duplication of work means significant cost saving and more focus on brand UX differentiation. Qt Automotive Suite is designed to integrate well with industry’s leading initiatives such as GENIVI and AGL, further increasing the reusability on the platform level for the entire industry. More detail can be found here.

With Qt Automotive Suite 5.11, Qt IVI has received updates highlighted as follow:

• In Qt Automotive Suite 2.0, we introduced the use of IVI APIs auto-generated from IDL files written in QFace. In 5.11, it also can also use QtRemoteObjects as an IPC provider. The latter allows further modularization of the IVI middleware across multiple processes with clear benefits in stability and a cleaner architecture.
• To make it easier to write and maintain the templates for the “ivigenerator”, a common template folder has been introduced. With this change we also introduced common Jinja macros, which removes a lot of common boiler-plate code in our macros.
• The “ivigenerator” now also supports additional annotation files. This can be useful if multiple parts are generated from the same QFace file, whereas every project needs different annotations.
• A new “QIviPendingReply” class was introduced. This class is a QFuture/Promise like API which can be used from C++ as well as from QML and is used to provide the return value of a function in an asynchronous manner. This is already fully integrated into the new QtRemoteObject based generator templates.

Comprehensive documentation

Without exception, we continuously improve our documentation. Qt Automotive Suite 5.11 comes with more comprehensive documentation and examples for most of development needs.

Summary

With Qt Automotive Suite 5.11, we have further strengthened our offering for the truly end-to-end solution for the digital cockpit HMI development. We brought in all new Qt 3D Studio 2.0 with many of the needed changes for automotive HMI designers, we added the fully certified Qt Safe Renderer for addressing the functional safety. We revamped the Neptune Reference UI that provides modern reference to digital cockpit design, and showcased how easy is to build digital cockpit with Qt Automotive Suit. We made significant number of improvements on all our software components. Finally, many thanks for the feedback especially from our customers and prospects.

Neptune Reference UI in depth

IVI

To highlight the multi-process UI capability of our Qt Application Manager, we redesigned the System UI with a strong focus on what’s possible with multi-process UI paradigm

Figure 3. Neptune IVI with focus on multi-process UI

As depicted by the figure above, we now introduced a new concept of “App Widgets” shown on the System UI, while each app widget runs in its own process implemented in Qt Application Manager. User can freely move each app up and down, open or close the app. When you resize the app window, the app will automatically display the right content based on window size, thus addressing the popular trend called Response UI.

We have added theming and accent color to the IVI settings, so a user can select dark and light theme with multiple accent colors, thus provides reference to how Qt Automotive Suite enables theming capability.

Figure 4. Theming and color accent

For navigation and mapping, we now leverage the Qt Location Mapbox GL Plugin, which provides the Mapbox mapping and styling by following Neptune UI theme and styles.

Figure 5. Mapbox GL plugin from Qt Location

The Vehicle application now contains an interactive 3D car model and adds controls visualizing user actions via manipulations of 3D objects via QML API. All this is completely based on Qt3D and so demonstrates that no additional software is required to visualize 3D objects in automotive use cases.

Figure 6. 3D car model and seamless integration with QML control

Instrument cluster

On the instrument cluster side, user can now share the content shown on the IVI onto the instrument cluster screen. Also, Qt Safe Renderer has been used to render the tell-tales as separate process via RTOS and hypervisor.

Figure 7. instrument cluster gets the Mapbox view shared by IVI

Inter-domain and inter-process communication

To cater the need for inter-process and inter-domain communication, we implemented a new Remote Settings Server based on Qt Remote Objects, which can serve multiple clients running on the same host or remote instances. For example, our new mobile app called “NeptuneControlApp” is capable of running on a mobile device. The app can communicate to the Remote Settings Server, and a user can, for instance, change the language of the digital cockpit as well as many other settings that are accessible. Perhaps the best part of the app is that it shares the auto-generated code base with Neptune UI and the Setting Server, thus matching to exposed setting options without manual work.

Figure 8. Remote Control App for Android and iOS

Check out the documentation at: https://doc.qt.io/Neptune3UI/index.html.

Thank you!
 

The post Introducing Qt Automotive Suite 5.11 appeared first on Qt Blog.

19 June 2018, basysKom Development Lead Frank Meerkötter and Michele Rossi from The Qt Company presented a webinar: Qt OPC UA – An Overview Driven by topics such as Industry 4.0 and IoT, OPC UA has established itself as the de facto standard for the communication of industrial devices and applications. Qt 5.11 ships with …Continue reading Qt Webinar by basysKom

本文翻译自：Qt 5.11 released

原文作者： Qt公司CTO兼Qt开源项目维护官Lars Knoll
翻译校审：Richard、Hongfei、Haipeng

5月22日，我们提发布了Qt 5.11。与以往一样，Qt 5.11增加了许多新功能，并修复了许多现有功能的bug。一起来看看这些很酷的新功能吧！

Qt Core 和Qt Network

我们对Qt Core做了许多细节优化。例如，一些工具类新增了引用传值的重载方法；补全了一些函数以保证API与STL的兼容性。我们的Item Model也增加了许多新特性。

Qt Network现在在IOS 上支持ALPN和HTTP / 2协议。在QNetworkRequest中附加一个Http2DirectAttribute，就可直接创建一个HTTP/2连接，而无需初始的协议协商。

Qt Core中的较大更新是对Unicode的支持。QChar、QString、QTextBoundaryFinder和双向文本算法现在完全兼容Unicode 10。

Qt GUI和Qt Widgets

支持Windows上的辅助功能是Qt 5.11的重点改进之一，我们基于Microsoft UI Automation重写了原先在Microsoft Active Accessibility 框架上的代码，从而增强了对Windows辅助功能的支持。

另一项主要工作是改进Windows上窗体样式，以更好支持高DPI显示。Linux上的打印对话框也被改头换面，对所有通用Unix打印系统(CUPS)选项提供了更好的支持。

我们修复了Qt Widgets的多个bug，并在QLineEdit中支持用鼠标快速选择文本。

以上是我们为所有台式机用户所做的更新。

Qt QML

我们为QML引擎做了许多优化，重写了QML的编译管线。新管线大幅提升了性能和可维护性。

新管线总是将QML编译为平台独立的字节码。引擎将这个字节码缓存进.qmlc文件。用户还可以利用qmlcompiler功能提前生成字节码。

新的字节码解释器在性能上有大幅提升。在我们的大多数测试用例中，相比Qt5.10的JIT技术，新的解释器已经能达到其80%到90%的性能。在解释器上层，我们还增加了新的热点JIT。因此在各个方面都可以击败我们旧版JIT技术。

Qt Quick 和 Qt Quick Controls

在Qt Quick方面，我们在Image元素中增加了对加载压缩纹理的支持，并提供.ktx 和.pkm两种容器文件格式。使用这种格式存储的图像文件可以直接被GPU处理。从而帮助减少应用程序的启动时间和内存消耗。

我们对Qt Quick Controls 2增加了许多小功能并修复了不少Bug。例如Buttons的自动重复属性、改进ScrollBars定位支持以及SpinBoxes的样式支持。

Qt Location

我们为Qt Location也做了许多改进。首先，最重要的新功能是实验性地增加了对turn-by-turn导航的支持。其次，Qt Location增加了一套实验性API，用于创建非QQuickItems的Map Object。MapPolyline对象的性能已有很大提升，图层功能现在也可以与Map Item结合使用。此外， Routing和Places对象已使用可扩展的API，添加了全新的WayPoint元素。最后，MapBox插件支持地理编码和Places。

Qt Webengine

按照惯例，我们将Qt Webengine的Chromium版本更新为Chromium 65。此外，我们现在支持嵌入式DevTools，不再需要打开另一个浏览器、可安装的cookie筛选器和配额权限。

Qt for Device Creation

Qt for Device Creation也同时拥有上述所有新功能。我们还一直在改进嵌入式专属的特性。

新功能还包括对基于硬件的图层的支持，目前的技术预览版仅能运行在支持VSP2硬件合成的设备上。该功能可用于诸如视频背景之类的功能，并且有助于提高性能，降低功耗。我们计划在今后的版本中支持更多平台、硬件组合。

我们改进了Qt SerialBus的CAN总线支持。KNX模块也有较大更新。此外，Qt 5.11还增加了一个支持OPC/UA的新模块，后者在Qt 5.11中以技术预览版的形式呈现。

其他改进

新的qdoc利用libclang编译，从而在文档中更好的支持新的C++标准。Qt Serialbus模块和Qt蓝牙模块方面也增强了对CAN总线和BTLE的支持。

Qt 5.11取消了对某些老版编译器和平台的支持，包括MSVC 2013， QNX 6.6和macOS 10.10。

Qt 3D 和 Qt 3D Studio

目前，我们正全力准备第二版Qt 3D Studio。其中包括基于Qt 3D、重写runtime，这会让用户在创建3D用户界面时能更好地集成Qt其他部分。Qt 3D也将有众多改进，包括全新功能、性能改进和Bug修复。Qt 3D Studio 2.0目前还处于测试阶段，我们会尽快推出正式版。

Qt对Webassembly和Python的支持

在Qt for Webassembly方面，我们正填补跨平台的最后一片空白；让用户能够以Web和浏览器为平台运行Qt应用程序。第一版已作为技术预览版发布。

此外，我们也在积极推动对Qt on Python的支持。第一版计划在本月发布。

感谢Qt 社区对我们的支持

Qt 5.11新增了许多新功能，并进行了性能的提升。如果没有那些为Qt贡献新功能、Bug修复、文档建立、示例和Bug报告的公司及个人开发者，我们无法完成这么多工作。要感谢的人实在太多了，在此特别鸣谢英特尔的Thiago Maciera长期以来对Qt Core的维护；合作伙伴basysKom的Jannis Voelker和Frank Meerkötter在OPC/UA上付出的心血；合作伙伴KDAB的Albert Astals Cid对CUPS printing的付出，Sean Harmer和Paul Lemire在Qt 3D上的贡献；还有，那些协助维护Qt各个模块的开发者们。感谢你们！

下载新版本

我们照例将对Qt 5.11提供为期一年的支持。如果您需要更长的支持期，推荐使用长期版Qt 5.9，我们将支持至2020年6月。当然，您可以向Qt公司购买延长服务。我们计划今年11月发布Qt 5.12，这将是一个长期支持的版本。

您可以从您的Qt帐户或www.qt.io/download下载Qt 5.11。希望您喜欢使用这个新版本！

The post 正式发布Qt 5.11 appeared first on Qt Blog.

Are you going to TU Automotive Detroit this year? So are we! Join us at the Qt booth #B136, have a chat and check out what’s new in the world of automotive HMIs with our latest demos #builtWithQt. 

• 2D and 3D instrument clusters. Watch how easy it is to design and implement both 2D and 3D instrument clusters with the same code base. 
• Enhanced UI development workflow. Shared tools between designers and developers mean faster iterations, better quality, and a consistent brand image. 

• A certifiably functionally safe digital cockpit with Hypervisor. Build multi-process UIs and incorporate external applications in a certified functionally safe two-screen UI. 
• E-bike with fastboot. An E-bike instrument cluster concept designed and implemented with Qt Quick, that shows how great an HMI on a low-end SoC, even without a GPU, can look.  

If you are attending the event and would like to set up a meeting with us contact Chuck Mallory, Director of Strategic Accounts, Automotive, at Chuck.Mallory@qt.io or 1(419) 305-0018.   

Looking forward to seeing you there! 

The post Meet us at TU Automotive Detroit 2018 – Booth #B136 appeared first on Qt Blog.

Hi.

In a previous blog post we touched upon the topic of creating Python bindings for the Qt libraries.

Today however, we’ll take a sneak peek at how you can create bindings for your own project.

We are happy to announce that Qt for Python will also include Shiboken– our binding generation tool.

Read the material below and you’ll obtain an understanding of how to generate Python bindings for a simple C++ library. Hopefully it will encourage you to do the same with custom libraries of your own.

As with any Qt project we are happy to review contributions to Shiboken, thus improving it for everyone.

Sample library

For the purposes of this post, we will use a slightly nonsensical custom library called Universe. It provides two classes: Icecream and Truck.
Icecreams are characterized by a flavor. And Truck serves as a vehicle of Icecream distribution for kids in a neighborhood. Pretty simple.

We would like to use those classes inside Python though. A use case would be adding additional ice cream flavors or checking whether ice cream distribution was successful.

In simple words, we want to provide Python bindings for Icecream and Truck, so that we can use them in a Python script of our own.

We will be omitting some content for brevity, but you can check the full source code inside the repository under pyside-setup/examples/samplebinding.

The C++ library

First, let’s take a look at the Icecream header:

class Icecream
{
public:
    Icecream(const std::string &flavor);
    virtual Icecream *clone();
    virtual ~Icecream();
    virtual const std::string getFlavor();

private:
    std::string m_flavor;
};

and the Truck header:

class Truck {
public:
    Truck(bool leaveOnDestruction = false);
    Truck(const Truck &other);
    Truck& operator=(const Truck &other);
    ~Truck();

    void addIcecreamFlavor(Icecream *icecream);
    void printAvailableFlavors() const;

    bool deliver() const;
    void arrive() const;
    void leave() const;

    void setLeaveOnDestruction(bool value);
    void setArrivalMessage(const std::string &message);

private:
    void clearFlavors();

    bool m_leaveOnDestruction = false;
    std::string m_arrivalMessage = "A new icecream truck has arrived!\n";
    std::vector m_flavors;
};

Most of the API should be easy enough to understand, but we’ll summarize the important bits:

• Icecream is a polymorphic type and is intended to be overridden
• getFlavor() will return the flavor depending on the actual derived type
• Truck is a value type that contains owned pointers, hence the copy constructor and co.
• Truck stores a vector of owned Icecream objects which can be added via addIcecreamFlavor()
• The Truck’s arrival message can be customized using setArrivalMessage()
• deliver() will tell us if the ice cream delivery was successful or not

Shiboken typesystem

To inform shiboken of the APIs we want bindings for, we provide a header file that includes the types we are interested in:

#ifndef BINDINGS_H
#define BINDINGS_H
#include "icecream.h"
#include "truck.h"
#endif // BINDINGS_H

In addition, shiboken also requires an XML typesystem file that defines the relationship between C++ and Python types:

The first important thing to notice is that we declare "bool" and "std::string" as primitive types.
A few of the C++ methods use these as parameter / return types and thus shiboken needs to know about them. It can then generate relevant conversion code between C++ and Python.
Most C++ primitive types are handled by shiboken without requiring additional code.

Next, we declare the two aforementioned classes. One of them as an “object-type” and the other as a “value-type”.

The main difference is that object-types are passed around in generated code as pointers, whereas value-types are copied (value semantics).

By specifying the names of the classes in the typesystem file, shiboken will automatically try to generate bindings for all methods declared in the classes, so there is no need
to mention all the method names manually…

Unless you want to somehow modify the function. Which leads us to the next topic: ownership rules.

Shiboken can’t magically know who is responsible for freeing C++ objects allocated in Python code. It can guess, but it’s not always the correct guess.
There can be many cases: Python should release the C++ memory when the ref count of the Python object becomes zero. Or Python should never delete the C++ object assuming that it will
be deleted at some point inside the C++ library. Or maybe it’s parented to another object (like QWidgets).

In our case the clone() method is only called inside the C++ library, and we assume that the C++ code will take care of releasing the cloned object.

As for addIcecreamFlavor(), we know that a Truck owns an Icecream object, and will remove it once the Truck is destroyed. Thus again, the ownership is set to “c++.”
If we didn’t specify the ownership rules, in this case, the C++ objects would be deleted when the corresponding Python names go out of scope.

Building

To build the Universe custom library and then generate bindings for it, we provide a well-documented, mostly generic CMakeLists.txt file, which you can reuse for your own libraries.

It mostly boils down to calling “cmake .” to configure the project and then building with the tool chain of your choice (we recommend the ‘(N)Makefiles’ generator though).

As a result of building the project, you end up with two shared libraries: libuniverse.(so/dylib/dll) and Universe.(so/pyd).
The former is the custom C++ library, and the latter is the Python module that can be imported from a Python script.

Of course there are also intermediate files created by shiboken (the .h / .cpp files generated for creating the Python bindings). Don’t worry about them unless you need to
debug why something fails to compile or doesn’t behave as it should. You can submit us a bug report then!

More detailed build instructions and things to take care of (especially on Windows) can be found in the example README.md file.

And finally, we get to the Python part.

Using the Python module

The following small script will use our Universe module, derive from Icecream, implement virtual methods, instantiate objects, and much more:

from Universe import Icecream, Truck

class VanillaChocolateIcecream(Icecream):
    def __init__(self, flavor=""):
        super(VanillaChocolateIcecream, self).__init__(flavor)

    def clone(self):
        return VanillaChocolateIcecream(self.getFlavor())

    def getFlavor(self):
        return "vanilla sprinked with chocolate"

class VanillaChocolateCherryIcecream(VanillaChocolateIcecream):
    def __init__(self, flavor=""):
        super(VanillaChocolateIcecream, self).__init__(flavor)

    def clone(self):
        return VanillaChocolateCherryIcecream(self.getFlavor())

    def getFlavor(self):
        base_flavor = super(VanillaChocolateCherryIcecream, self).getFlavor()
        return base_flavor + " and a cherry"

if __name__ == '__main__':
    leave_on_destruction = True
    truck = Truck(leave_on_destruction)

    flavors = ["vanilla", "chocolate", "strawberry"]
    for f in flavors:
        icecream = Icecream(f)
        truck.addIcecreamFlavor(icecream)

    truck.addIcecreamFlavor(VanillaChocolateIcecream())
    truck.addIcecreamFlavor(VanillaChocolateCherryIcecream())

    truck.arrive()
    truck.printAvailableFlavors()
    result = truck.deliver()

    if result:
        print("All the kids got some icecream!")
    else:
        print("Aww, someone didn't get the flavor they wanted...")

    if not result:
        special_truck = Truck(truck)
        del truck

        print("")
        special_truck.setArrivalMessage("A new SPECIAL icecream truck has arrived!\n")
        special_truck.arrive()
        special_truck.addIcecreamFlavor(Icecream("SPECIAL *magical* icecream"))
        special_truck.printAvailableFlavors()
        special_truck.deliver()
        print("Now everyone got the flavor they wanted!")
        special_truck.leave()

After importing the classes from our module, we create two derived Icecream types which have customized “flavours”.

We then create a truck, add some regular flavored Icecreams to it, and the two special ones.

We try to deliver the ice cream.
If the delivery fails, we create a new truck with the old one’s flavors copied over, and a new *magical* flavor that will surely satisfy all customers.

The script above succinctly shows usage of deriving from C++ types, overriding virtual methods, creating and destroying objects, etc.

As mentioned above, the full source and additional build instructions can be found in the project repository under pyside-setup/examples/samplebinding.

We hope that this small introduction showed you the power of Shiboken, how we leverage it to create Qt for Python, and how you could too!

Happy binding!

The post Write your own Python bindings appeared first on Qt Blog.

In our first part of this series, we looked at how to set up messages, combine them, and reduce their overhead in the context of telemetry sensors.

This part focuses on the payload of messages and how to optimize them.

There are multiple methods to serialize an object with Qt. In part one, we used JSON. For this, all sensor information is stored in a QJsonObject and a QJsonDocument takes care to stream values into a QByteArray.

QJsonObject jobject;

jobject["SensorID"] = m_id;

jobject["AmbientTemperature"] = m_ambientTemperature;

jobject["ObjectTemperature"] = m_objectTemperature;

jobject["AccelerometerX"] = m_accelerometerX;

jobject["AccelerometerY"] = m_accelerometerY;

jobject["AccelerometerZ"] = m_accelerometerZ;

jobject["Altitude"] = m_altitude;

jobject["Light"] = m_light;

jobject["Humidity"] = m_humidity;

QJsonDocument doc( jobject );

 

return doc.toJson();

JSON has several advantages:

• Textual JSON is declarative, which makes it readable to humans
• The information is structured
• Exchanging generic information is easy
• JSON allows extending messages with additional values
• Many solutions exist to receive and parse JSON in cloud-based solutions

However, there are some limitations to this approach. First, creating a JSON message can be a heavy operation taking many cycles. The benchmark in part 2 of our examples repository highlights that serializing and de-serializing 10.000 messages takes around 263 ms. That might not read like a significant number per message, but in this context time equals energy. This can significantly impact a sensor which is designed to run for years without being charged.

Another aspect is that the payload for an MQTT message per sensor update is 346 bytes. Given that the sensor sends just eight doubles and one capped string, this can be a potentially huge overhead.

Inside the comments of my previous post, using QJsonDocument::Compact has been recommended, which reduces the payload size to 290 bytes in average.

So, how can we improve on this?

Remember I was referring to textual JSON before? As most of you know, there is also binary JSON, which might reduce readability, but all other aspects are still relevant. Most importantly, from our benchmarks we can see that a simple switch of doc.toJson() to doc.toBinaryData() will double the speed of the test, reducing the iteration of the benchmark to 125msecs.

Checking on the payload, the message size is now at 338 bytes, the difference is almost neglectable. However, this might change in different scenarios, for instance, if you add more strings inside a message.

Depending on the requirements and whether third-party solutions can be added to the project, other options are available.

In case the project resides “within the Qt world” and the whole flow of data is determined and not about to change, QDataStream is a viable option.

Adding support for this in the SensorInformation class requires two additional operators

QDataStream &operator<<(QDataStream &, const SensorInformation &);
QDataStream &operator>>(QDataStream &, SensorInformation &);

The implementation is straightforward as well. Below it is shown for the serialization:

QDataStream &operator<<(QDataStream &out, const SensorInformation &item)
{
    QDataStream::FloatingPointPrecision prev = out.floatingPointPrecision();
    out.setFloatingPointPrecision(QDataStream::DoublePrecision);
    out << item.m_id
        << item.m_ambientTemperature
        << item.m_objectTemperature
        << item.m_accelerometerX
        << item.m_accelerometerY
        << item.m_accelerometerZ
        << item.m_altitude
        << item.m_light
        << item.m_humidity;
    out.setFloatingPointPrecision(prev);
    return out;}

Consulting the benchmarks, using QDataStream resulted in only 26 msecs for this test case, which is close to 10 times faster to textual JSON. Furthermore, the average message size is only 84 bytes, compared to 290. Hence, if above limitations are acceptable, QDataStream is certainly a viable option.

If the project lets you add in further third-party components, one of the most prominent serialization solutions is Google’s Protocol Buffers (protobuf).

To add protobuf to our solution a couple of changes need to be done. First, protobuf uses an IDL to describe the structures of data or messages. The SensorInformation design is

syntax = "proto2";

package serialtest;

message Sensor {
    required string id = 1;
    required double ambientTemperature = 2;
    required double objectTemperature = 3;
    required double accelerometerX = 4;
    required double accelerometerY = 5;
    required double accelerometerZ = 6;
    required double altitude = 7;
    required double light = 8;
    required double humidity = 9;
}

To add protobuf’s code generator (protoc) to a qmake project, you must add an extra compiler step similar to this:

PROTO_FILE = sensor.proto
protoc.output = $${OUT_PWD}/${QMAKE_FILE_IN_BASE}.pb.cc
protoc.commands = $${PROTO_PATH}/bin/protoc -I=$$relative_path($${PWD}, $${OUT_PWD}) --cpp_out=. ${QMAKE_FILE_NAME}
protoc.variable_out = GENERATED_SOURCES
protoc.input = PROTO_FILE
QMAKE_EXTRA_COMPILERS += protoc

Next, to have a comparable benchmark in terms of object size, the generated struct is used as a member for a SensorInformationProto class, which inherits QObject, just like for the QDataStream and JSON example.

class SensorInformationProto : public QObject
{
    Q_OBJECT
    Q_PROPERTY(double ambientTemperature READ ambientTemperature WRITE setAmbientTemperature NOTIFY ambientTemperatureChanged)
[...]

public:
    SensorInformationProto(const std::string &pr);
[...]

     std::string serialize() const;
 [...]

private:
    serialtest::Sensor m_protoInfo;
};

The serialization function of protoInfo is generated by protoc, so the step to create the payload to be transmitted looks like this:

std::string SensorInformationProto::serialize() const
{
    std::string res;
    m_protoInfo.SerializeToString(&res);
    return res;
}

Note that compared to the previous solutions, protobuf uses std::string. This means you are losing capabilities of QString, unless the string is stored as a byte array (manual conversion is required). Then again, this will slow down the whole process due to parsing.

From a performance perspective, the benchmarks results look promising. The 10.000 items benchmark only takes 5 ms, with an average message size of 82 bytes.

As a summary, the following table visualizes the various approaches:

One promising alternative is CBOR, which is currently getting implemented by Thiago Macieira for Qt 5.12. However, as development is in progress it has been too early to be included in this post. From discussions on our mailing list, results are looking promising though, with a significant performance advantage over JSON, but with all its benefits.

We have seen various approaches to serialize data into the payload of an MQTT message. Those can be done purely within Qt, or with external solutions (like protobuf). Integration of external solutions into Qt is easy.

As a final disclaimer, I would like to highlight that those benchmarks are all based on the scenario of the sensor demo. The amount of data values per message is fairly small. If those structs are bigger in size, the results might differ and different approaches might lead to the better results.

In our next installment, we will be looking at message integration with DDS. For an overview of all the articles in our automation mini-series, please check out Lars’ post.

The post Serialization in and with Qt appeared first on Qt Blog.

With all the advances being made in Qt 3D, we wanted to create some new examples showing some of what it can do. To get us started, we decided to use an existing learning framework, so we followed the open source Tower Defence course, which you can find at CGCookie. Being a game, it allows an interactive view of everything at work, which is very useful.

We found it to be so diverse, that we are now implementing Parts 2 and 3 of the game into Qt 3D. However you don’t have to wait for that, you can start now by following the steps we took.

The setup

These instructions will help you setup for Qt 5.11.0 .

To start, turn to your QtCreator and create a new Qt Console Application, set to run on your Qt 5.11.0 kit.

A Qt Console Application doesn’t come with too much ‘plumbing’. A lot of the other options will attempt to give you starting files that aren’t required or in some cases, the wrong type entirely.

Let’s edit it to fit our needs by opening up the .pro file and adding the following:

First remove the QT += core and QT -= gui lines if they are present.

QT += 3dcore 3drender 3dinput 3dquick 3dquickextras qml quick

Then, if the lines CONFIG += c++11 console and CONFIG -= app_bundle are present, remove them too. Now back on the main.cpp file we need to edit our “includes” from the Qt 3D library.

Replace the #include QCoreApplication with #include QGuiApplication and add these lines:

#include 
#include 
#include 

Within the main block we now have to edit QCoreApplication a(argc, argv); to mirror our include change. So change it to:

QGuiApplication a(argc, argv);

Before the first build / run we should add something to look at. Adding the following block of code before the return statement will provide us with a window:

Qt3DExtras::Quick::Qt3DQuickWindow view;
view.setSource(QUrl("qrc:/main.qml"));
view.show();

Commenting out the line referring to main.qml will allow you to build and run what you have already. If everything has gone to plan, you will get a white window appear. Now you can uncomment the line and continue onwards!

QRC creation

Okay, let’s get rid of the boring white scene and get something in there. Right-click the ‘Sources’ folder and select ‘Add New…’. From here select the Qt > QML File (Qt Quick 2) option. We’ve gone and named it main so that after clicking next till the end you should now have a main.qml and a main.cpp.

This QML file is now going to hold our scene, but to do that we need some resources. We will achieve this by adding a Qt Resource File, just as we did for main.qml – assuming you have an obj with accompanying textures placed in an assets folder within the project.

So this time right-click on the project folder and select ‘Add New…’. From the Qt menu, select ‘Qt Resource File’ and name it something fitting. When this opens it will look noticeably different to the qml and cpp files. At the bottom you will see the self-descriptive; Add, Remove and Remove Missing Files buttons. Click the ‘Add’ button and select ‘Add Prefix’. Now remove everything from the Prefix: text input just leaving the ‘/‘. Click the ‘Add’ button again, this time selecting the ‘Add Files’ option.

Navigate to your obj and texture files and add them all to the qrc, save and close it. If everything went to plan, a ‘Resources’ folder will now be visible in the Projects window on the left.

Follow this again and add main.qml to the qrc in the same way.

One last thing we need before playing with the scene is a skymap. With the files placed in your assets folder, go ahead and add the skymap to the qrc file.

The necessities

Back to the QML file now, rename the Item { } to be an Entity { } and give it the id: scene. Entity is not recognised because we are missing some imports. Hitting F1 with Entity selected shows us that we need to import Qt3D.Core 2.0, so add this to the imports at the top of the file.

There are certain components that a 3D scene must have, a camera and Render settings being two of those. For this example, we’ll throw in a camera controller too so we can move around the scene.

components: [
    RenderSettings {
        activeFrameGraph: ForwardRenderer {
            camera: mainCamera
            clearColor: Qt.rgba(0.1, 0.1, 0.1, 1.0)
        }
    },
    // Event Source will be set by the Qt3DQuickWindow
    InputSettings { }
]

Camera {
    id: mainCamera
    position: Qt.vector3d(30, 30, 30)
    viewCenter: Qt.vector3d(0, 0, 0)
}

FirstPersonCameraController {
    camera: mainCamera
    linearSpeed: 10
    lookSpeed: 50
}

Here we see that Camera is not recognised, so let’s get the missing import.

The sky is the limit

Let’s put that skymap to use now. Back in the main.cpp file, we need to add code to check if we’re on MAC or not. If you remember, this was due to MAC not supporting compressed files and needing its own versions. After the QGuiApplication line, put in the following:

#if defined(Q_OS_MAC)
    const QString envmapFormat = QLatin1String("-16f");
#else
    const QString envmapFormat = QLatin1String("");
#endif

Then after the Qt3DExtras line, add the following:

auto context = view.engine()->qmlEngine()->rootContext();
context->setContextProperty(QLatin1String("_envmapFormat"), envmapFormat);

If you try to build at this point, you will notice various imports missing. One for FirstPersonCameraController, one for InputSettings and TexturedMetalRoughtMaterial. Hitting F1 on FirstPersonCameraController will give you import Qt3D.Extras 2.0 and F1 on InputSettings will give you import Qt3D.Input 2.0 but then later you’ll hit a snag. TexturedMetalRoughtMaterial may not turn up any documentation but we’ll be kind enough to give you the answer… edit the Qt3D.Extras 2.0 to be 2.9 instead. If this now works you will get a dark grey window.

Barrel of laughs

The final part will be our mesh, we chose a barrel, and the skymap for it to reflect (although this might not be visible).

In main.qml after the InputSettings{}, throw in the following:

EnvironmentLight {
    id: envLight
    irradiance: TextureLoader {
        source: "qrc:/path/to/your/file" + _envmapFormat + "_cube_irradiance.dds"

        minificationFilter: Texture.LinearMipMapLinear
        magnificationFilter: Texture.Linear
        wrapMode {
            x: WrapMode.ClampToEdge
            y: WrapMode.ClampToEdge
        }
        generateMipMaps: false
    }
    specular: TextureLoader {
        source: "qrc:/path/to/your/file" + _envmapFormat + "_cube_specular.dds"
                
        minificationFilter: Texture.LinearMipMapLinear
        magnificationFilter: Texture.Linear
        wrapMode {
            x: WrapMode.ClampToEdge
            y: WrapMode.ClampToEdge
        }
        generateMipMaps: false
    }
}

You can hit build now to check it’s working, but the scene will still be pretty boring. Throw in your obj to get some eye candy. Here is the code we used after EnvironmentLight:

Mesh {
    source: "qrc:/your/model.obj"
},
Transform {
    translation: Qt.vector3d(4, 0, 2)
},
TexturedMetalRoughMaterial {
    baseColor: TextureLoader {
        format: Texture.SRGB8_Alpha8
        source: "qrc:/path/to/your/Base_Color.png"
    }
    metalness: TextureLoader { source: "qrc:/path/to/your/Metallic.png" }
    roughness: TextureLoader { source: "qrc:/path/to/your/Roughness.png" }
    normal: TextureLoader { source: "qrc:/path/to/your/Normal_OpenGL.png" }
    ambientOcclusion: TextureLoader { source: "qrc:/path/to/your/Mixed_AO.png" }
}

Finally, hit build and then run.

The barrel viewed at the end of What A Mesh pt1

The post What a mesh! appeared first on KDAB.

KDAB was sponsor of this annual C++ event run by the C++ Community for the C++ Community in Italy, which was founded some five years ago and is growing fast.

Around 200 people showed up for “++ it”, 50 more than last year, and were treated to an excellent program.

There was a mix of talks in either English or Italian, including ‘Debug C++ Without Running‘ by Anastasia Kazakova, ‘C++ Barbarian Quiz & Introduction to Conan C/C++ Package Manager‘ from Diego Rodriguez-Losada Gonzalez and one from Vittorio Romeo on ‘Zero-allocation & no type erasure futures‘, all of which KDAB particularly enjoyed.

You can see the full program and a post-event report here.

The post KDAB at Italian C++, Milan appeared first on KDAB.

We are happy to announce the release of Qt Creator 4.7 RC!

After 2 weeks and 70 changes since the Beta2, we think that we are almost ready for the final release of Qt Creator 4.7. So this is a good time to give us some last feedback, best done through our bug tracker.

Get Qt Creator 4.7 RC

The opensource version is available on the Qt download page, and you find commercially licensed packages on the Qt Account Portal. Qt Creator 4.7 RC is also available under Preview>Qt Creator 4.7.0-rc1 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.7 RC released appeared first on Qt Blog.

Hi.

In a previous blog post we touched upon the topic of creating Python bindings for the Qt libraries.

Today however, we’ll take a sneak peek at how you can create bindings for your own project.

We are happy to announce that Qt for Python will also include Shiboken– our binding generation tool.

Read the material below and you’ll obtain an understanding of how to generate Python bindings for a simple C++ library. Hopefully it will encourage you to do the same with custom libraries of your own.

As with any Qt project we are happy to review contributions to Shiboken, thus improving it for everyone.

Sample library

For the purposes of this post, we will use a slightly nonsensical custom library called Universe. It provides two classes: Icecream and Truck.
Icecreams are characterized by a flavor. And Truck serves as a vehicle of Icecream distribution for kids in a neighborhood. Pretty simple.

We would like to use those classes inside Python though. A use case would be adding additional ice cream flavors or checking whether ice cream distribution was successful.

In simple words, we want to provide Python bindings for Icecream and Truck, so that we can use them in a Python script of our own.

We will be omitting some content for brevity, but you can check the full source code inside the repository under pyside-setup/examples/samplebinding.

The C++ library

First, let’s take a look at the Icecream header:

class Icecream
{
public:
    Icecream(const std::string &flavor);
    virtual Icecream *clone();
    virtual ~Icecream();
    virtual const std::string getFlavor();

private:
    std::string m_flavor;
};

and the Truck header:

class Truck {
public:
    Truck(bool leaveOnDestruction = false);
    Truck(const Truck &other);
    Truck& operator=(const Truck &other);
    ~Truck();

    void addIcecreamFlavor(Icecream *icecream);
    void printAvailableFlavors() const;

    bool deliver() const;
    void arrive() const;
    void leave() const;

    void setLeaveOnDestruction(bool value);
    void setArrivalMessage(const std::string &message);

private:
    void clearFlavors();

    bool m_leaveOnDestruction = false;
    std::string m_arrivalMessage = "A new icecream truck has arrived!\n";
    std::vector m_flavors;
};

Most of the API should be easy enough to understand, but we’ll summarize the important bits:

• Icecream is a polymorphic type and is intended to be overridden
• getFlavor() will return the flavor depending on the actual derived type
• Truck is a value type that contains owned pointers, hence the copy constructor and co.
• Truck stores a vector of owned Icecream objects which can be added via addIcecreamFlavor()
• The Truck’s arrival message can be customized using setArrivalMessage()
• deliver() will tell us if the ice cream delivery was successful or not

Shiboken typesystem

To inform shiboken of the APIs we want bindings for, we provide a header file that includes the types we are interested in:

#ifndef BINDINGS_H
#define BINDINGS_H
#include "icecream.h"
#include "truck.h"
#endif // BINDINGS_H

In addition, shiboken also requires an XML typesystem file that defines the relationship between C++ and Python types:

The first important thing to notice is that we declare "bool" and "std::string" as primitive types.
A few of the C++ methods use these as parameter / return types and thus shiboken needs to know about them. It can then generate relevant conversion code between C++ and Python.
Most C++ primitive types are handled by shiboken without requiring additional code.

Next, we declare the two aforementioned classes. One of them as an “object-type” and the other as a “value-type”.

The main difference is that object-types are passed around in generated code as pointers, whereas value-types are copied (value semantics).

By specifying the names of the classes in the typesystem file, shiboken will automatically try to generate bindings for all methods declared in the classes, so there is no need
to mention all the method names manually…

Unless you want to somehow modify the function. Which leads us to the next topic: ownership rules.

Shiboken can’t magically know who is responsible for freeing C++ objects allocated in Python code. It can guess, but it’s not always the correct guess.
There can be many cases: Python should release the C++ memory when the ref count of the Python object becomes zero. Or Python should never delete the C++ object assuming that it will
be deleted at some point inside the C++ library. Or maybe it’s parented to another object (like QWidgets).

In our case the clone() method is only called inside the C++ library, and we assume that the C++ code will take care of releasing the cloned object.

As for addIcecreamFlavor(), we know that a Truck owns an Icecream object, and will remove it once the Truck is destroyed. Thus again, the ownership is set to “c++.”
If we didn’t specify the ownership rules, in this case, the C++ objects would be deleted when the corresponding Python names go out of scope.

Building

To build the Universe custom library and then generate bindings for it, we provide a well-documented, mostly generic CMakeLists.txt file, which you can reuse for your own libraries.

It mostly boils down to calling “cmake .” to configure the project and then building with the tool chain of your choice (we recommend the ‘(N)Makefiles’ generator though).

As a result of building the project, you end up with two shared libraries: libuniverse.(so/dylib/dll) and Universe.(so/pyd).
The former is the custom C++ library, and the latter is the Python module that can be imported from a Python script.

Of course there are also intermediate files created by shiboken (the .h / .cpp files generated for creating the Python bindings). Don’t worry about them unless you need to
debug why something fails to compile or doesn’t behave as it should. You can submit us a bug report then!

More detailed build instructions and things to take care of (especially on Windows) can be found in the example README.md file.

And finally, we get to the Python part.

Using the Python module

The following small script will use our Universe module, derive from Icecream, implement virtual methods, instantiate objects, and much more:

from Universe import Icecream, Truck

class VanillaChocolateIcecream(Icecream):
    def __init__(self, flavor=""):
        super(VanillaChocolateIcecream, self).__init__(flavor)

    def clone(self):
        return VanillaChocolateIcecream(self.getFlavor())

    def getFlavor(self):
        return "vanilla sprinked with chocolate"

class VanillaChocolateCherryIcecream(VanillaChocolateIcecream):
    def __init__(self, flavor=""):
        super(VanillaChocolateIcecream, self).__init__(flavor)

    def clone(self):
        return VanillaChocolateCherryIcecream(self.getFlavor())

    def getFlavor(self):
        base_flavor = super(VanillaChocolateCherryIcecream, self).getFlavor()
        return base_flavor + " and a cherry"

if __name__ == '__main__':
    leave_on_destruction = True
    truck = Truck(leave_on_destruction)

    flavors = ["vanilla", "chocolate", "strawberry"]
    for f in flavors:
        icecream = Icecream(f)
        truck.addIcecreamFlavor(icecream)

    truck.addIcecreamFlavor(VanillaChocolateIcecream())
    truck.addIcecreamFlavor(VanillaChocolateCherryIcecream())

    truck.arrive()
    truck.printAvailableFlavors()
    result = truck.deliver()

    if result:
        print("All the kids got some icecream!")
    else:
        print("Aww, someone didn't get the flavor they wanted...")

    if not result:
        special_truck = Truck(truck)
        del truck

        print("")
        special_truck.setArrivalMessage("A new SPECIAL icecream truck has arrived!\n")
        special_truck.arrive()
        special_truck.addIcecreamFlavor(Icecream("SPECIAL *magical* icecream"))
        special_truck.printAvailableFlavors()
        special_truck.deliver()
        print("Now everyone got the flavor they wanted!")
        special_truck.leave()

After importing the classes from our module, we create two derived Icecream types which have customized “flavours”.

We then create a truck, add some regular flavored Icecreams to it, and the two special ones.

We try to deliver the ice cream.
If the delivery fails, we create a new truck with the old one’s flavors copied over, and a new *magical* flavor that will surely satisfy all customers.

The script above succinctly shows usage of deriving from C++ types, overriding virtual methods, creating and destroying objects, etc.

As mentioned above, the full source and additional build instructions can be found in the project repository under pyside-setup/examples/samplebinding.

We hope that this small introduction showed you the power of Shiboken, how we leverage it to create Qt for Python, and how you could too!

Happy binding!

The post Write your own Python bindings appeared first on Qt Blog.

There has been a lot of back and forth around the use of Free Software in public administration. One of the latest initiatives in this area was started by the Free Software Foundation Europe, FSFE. It focuses on the slogan: Public Money – Public Code. There are various usage scenarios for Free Software in public administration. The span ranges from the use of backend technology over user-facing software, e.g. LibreOffice, up to providing a whole free desktop for the administrative staff in a public service entity such as a city council. In this article we will focus on the latter.

When the desktops in an administration are migrated to Linux, the administration becomes a distribution provider. An example for this is the LiMux desktop, that powers the administration of the city of Munich since 2012.

LiMux is a distribution, maintained by the central IT department of the City of Munich. Technically, it builds upon Kubuntu. It provides specific patches, a modified user experience and an automatic distribution system, so all desktops in all departments of the city can be easily administered and offer a consistent user experience.

Distributions in the Free Software ecosystem have different roles, one of them surely being the provider of the finishing touches, especially to important software for its own users. Obviously public administration has special demands. Workflows and documents for example have a totally different importance than for the average Kubuntu user.

In Munich for example, architects in one department complained that Okular, the LiMux and KDE pdf reader, would freeze when they tried to open large construction plans. When the city investigated this issue further, they found out that actually Okular wouldn’t freeze, but loading these large maps would simply occupy Okular for quite a while, making the user think it crashed.

Naturally the City of Munich wanted this issue fixed. But this use case is rather rare for the voluntary Free Software Developer, as only few user groups, like architects, are actually in the situation of having to deal with such large files, so it was unlikely that this bug would be fixed on a voluntary basis.

Since the city does not have enough developer power to fix all such issues themselves, they looked to KDAB for external support. With our KDE and Qt expertise, we were well-positioned to help. Together we identified that, instead of the suggested busy indicator for Okular the City of Munich wanted, progressive loading would be an even better solution. It allows the user to visually follow the loading process and makes it possible for the user to interact with large files as early as possible. And as the City does not want to maintain a patch that fixes this issue for them locally, we also helped them to get all the patches upstream.

This way all efforts are made available for the architects at the City of Munich and also for the general public. In the same spirit we have fixed numerous issues for the City of Munich all around KDE and Qt. As another example: we brought back extended settings to the Qt print dialogue. This allows the City of Munich to make use of all of the functionalities of their high-tech printer, like sorting, stapling and so on. You can read more about KDAB’s work on this here.

Becoming a distribution implies a lot of responsibility for a public administration and KDAB is proud to offer reliable backup for any administration that decides to follow the Linux, Qt and KDE path.

Afternote: Recent developments mean that the City has decided to revert the migration back to Microsoft by 2020. The good news is that most changes and adjustments they have made are available upstream and other administrations can build their own solutions upon them.

The post The LiMux desktop and the City of Munich appeared first on KDAB.

With all the advances being made in Qt 3D, we wanted to create some new examples showing some of what it can do. To get us started, we decided to use an existing learning framework, so we followed the open source Tower Defence course, which you can find at CGCookie. Being a game, it allows an interactive view of everything at work, which is very useful.

We found it to be so diverse, that we are now implementing Parts 2 and 3 of the game into Qt 3D. However you don’t have to wait for that, you can start now by following the steps we took.

The setup

These instructions will help you setup for Qt 5.11.0 .

To start, turn to your QtCreator and create a new Qt Console Application, set to run on your Qt 5.11.0 kit.

A Qt Console Application doesn’t come with too much ‘plumbing’. A lot of the other options will attempt to give you starting files that aren’t required or in some cases, the wrong type entirely.

Let’s edit it to fit our needs by opening up the .pro file and adding the following:

First remove the QT += core and QT -= gui lines if they are present.

QT += 3dcore 3drender 3dinput 3dquick 3dquickextras qml quick

Then, if the lines CONFIG += c++11 console and CONFIG -= app_bundle are present, remove them too. Now back on the main.cpp file we need to edit our “includes” from the Qt 3D library.

Replace the #include QCoreApplication with #include QGuiApplication and add these lines:

#include 
#include 
#include 

Within the main block we now have to edit QCoreApplication a(argc, argv); to mirror our include change. So change it to:

QGuiApplication a(argc, argv);

Before the first build / run we should add something to look at. Adding the following block of code before the return statement will provide us with a window:

Qt3DExtras::Quick::Qt3DQuickWindow view;
view.setSource(QUrl("qrc:/main.qml"));
view.show();

Commenting out the line referring to main.qml will allow you to build and run what you have already. If everything has gone to plan, you will get a white window appear. Now you can uncomment the line and continue onwards!

QRC creation

Okay, let’s get rid of the boring white scene and get something in there. Right-click the ‘Sources’ folder and select ‘Add New…’. From here select the Qt > QML File (Qt Quick 2) option. We’ve gone and named it main so that after clicking next till the end you should now have a main.qml and a main.cpp.

This QML file is now going to hold our scene, but to do that we need some resources. We will achieve this by adding a Qt Resource File, just as we did for main.qml – assuming you have an obj with accompanying textures placed in an assets folder within the project.

So this time right-click on the project folder and select ‘Add New…’. From the Qt menu, select ‘Qt Resource File’ and name it something fitting. When this opens it will look noticeably different to the qml and cpp files. At the bottom you will see the self-descriptive; Add, Remove and Remove Missing Files buttons. Click the ‘Add’ button and select ‘Add Prefix’. Now remove everything from the Prefix: text input just leaving the ‘/‘. Click the ‘Add’ button again, this time selecting the ‘Add Files’ option.

Navigate to your obj and texture files and add them all to the qrc, save and close it. If everything went to plan, a ‘Resources’ folder will now be visible in the Projects window on the left.

Follow this again and add main.qml to the qrc in the same way.

One last thing we need before playing with the scene is a skymap. With the files placed in your assets folder, go ahead and add the skymap to the qrc file.

The necessities

Back to the QML file now, rename the Item { } to be an Entity { } and give it the id: scene. Entity is not recognised because we are missing some imports. Hitting F1 with Entity selected shows us that we need to import Qt3D.Core 2.0, so add this to the imports at the top of the file.

There are certain components that a 3D scene must have, a camera and Render settings being two of those. For this example, we’ll throw in a camera controller too so we can move around the scene.

components: [
    RenderSettings {
        activeFrameGraph: ForwardRenderer {
            camera: mainCamera
            clearColor: Qt.rgba(0.1, 0.1, 0.1, 1.0)
        }
    },
    // Event Source will be set by the Qt3DQuickWindow
    InputSettings { }
]

Camera {
    id: mainCamera
    position: Qt.vector3d(30, 30, 30)
    viewCenter: Qt.vector3d(0, 0, 0)
}

FirstPersonCameraController {
    camera: mainCamera
    linearSpeed: 10
    lookSpeed: 50
}

Here we see that Camera is not recognised, so let’s get the missing import.

The sky is the limit

Let’s put that skymap to use now. Back in the main.cpp file, we need to add code to check if we’re on MAC or not. If you remember, this was due to MAC not supporting compressed files and needing its own versions. After the QGuiApplication line, put in the following:

#if defined(Q_OS_MAC)
    const QString envmapFormat = QLatin1String("-16f");
#else
    const QString envmapFormat = QLatin1String("");
#endif

Then after the Qt3DExtras line, add the following:

auto context = view.engine()->qmlEngine()->rootContext();
context->setContextProperty(QLatin1String("_envmapFormat"), envmapFormat);

If you try to build at this point, you will notice various imports missing. One for FirstPersonCameraController, one for InputSettings and TexturedMetalRoughtMaterial. Hitting F1 on FirstPersonCameraController will give you import Qt3D.Extras 2.0 and F1 on InputSettings will give you import Qt3D.Input 2.0 but then later you’ll hit a snag. TexturedMetalRoughtMaterial may not turn up any documentation but we’ll be kind enough to give you the answer… edit the Qt3D.Extras 2.0 to be 2.9 instead. If this now works you will get a dark grey window.

Barrel of laughs

The final part will be our mesh, we chose a barrel, and the skymap for it to reflect (although this might not be visible).

In main.qml after the InputSettings{}, throw in the following:

EnvironmentLight {
    id: envLight
    irradiance: TextureLoader {
        source: "qrc:/path/to/your/file" + _envmapFormat + "_cube_irradiance.dds"

        minificationFilter: Texture.LinearMipMapLinear
        magnificationFilter: Texture.Linear
        wrapMode {
            x: WrapMode.ClampToEdge
            y: WrapMode.ClampToEdge
        }
        generateMipMaps: false
    }
    specular: TextureLoader {
        source: "qrc:/path/to/your/file" + _envmapFormat + "_cube_specular.dds"
                
        minificationFilter: Texture.LinearMipMapLinear
        magnificationFilter: Texture.Linear
        wrapMode {
            x: WrapMode.ClampToEdge
            y: WrapMode.ClampToEdge
        }
        generateMipMaps: false
    }
}

You can hit build now to check it’s working, but the scene will still be pretty boring. Throw in your obj to get some eye candy. Here is the code we used after EnvironmentLight:

Mesh {
    source: "qrc:/your/model.obj"
},
Transform {
    translation: Qt.vector3d(4, 0, 2)
},
TexturedMetalRoughMaterial {
    baseColor: TextureLoader {
        format: Texture.SRGB8_Alpha8
        source: "qrc:/path/to/your/Base_Color.png"
    }
    metalness: TextureLoader { source: "qrc:/path/to/your/Metallic.png" }
    roughness: TextureLoader { source: "qrc:/path/to/your/Roughness.png" }
    normal: TextureLoader { source: "qrc:/path/to/your/Normal_OpenGL.png" }
    ambientOcclusion: TextureLoader { source: "qrc:/path/to/your/Mixed_AO.png" }
}

Finally, hit build and then run.

The barrel viewed at the end of What A Mesh pt1

The post What a mesh! appeared first on KDAB.

KDAB was sponsor of this annual C++ event run by the C++ Community for the C++ Community in Italy, which was founded some five years ago and is growing fast.

Around 200 people showed up for “++ it”, 50 more than last year, and were treated to an excellent program.

There was a mix of talks in either English or Italian, including ‘Debug C++ Without Running‘ by Anastasia Kazakova, ‘C++ Barbarian Quiz & Introduction to Conan C/C++ Package Manager‘ from Diego Rodriguez-Losada Gonzalez and one from Vittorio Romeo on ‘Zero-allocation & no type erasure futures‘, all of which KDAB particularly enjoyed.

You can see the full program and a post-event report here.

The post KDAB at Italian C++, Milan appeared first on KDAB.

There has been a lot of back and forth around the use of Free Software in public administration. One of the latest initiatives in this area was started by the Free Software Foundation Europe, FSFE. It focuses on the slogan: Public Money – Public Code. There are various usage scenarios for Free Software in public administration. The span ranges from the use of backend technology over user-facing software, e.g. LibreOffice, up to providing a whole free desktop for the administrative staff in a public service entity such as a city council. In this article we will focus on the latter.

When the desktops in an administration are migrated to Linux, the administration becomes a distribution provider. An example for this is the LiMux desktop, that powers the administration of the city of Munich since 2012.

LiMux is a distribution, maintained by the central IT department of the City of Munich. Technically, it builds upon Kubuntu. It provides specific patches, a modified user experience and an automatic distribution system, so all desktops in all departments of the city can be easily administered and offer a consistent user experience.

Distributions in the Free Software ecosystem have different roles, one of them surely being the provider of the finishing touches, especially to important software for its own users. Obviously public administration has special demands. Workflows and documents for example have a totally different importance than for the average Kubuntu user.

In Munich for example, architects in one department complained that Okular, the LiMux and KDE pdf reader, would freeze when they tried to open large construction plans. When the city investigated this issue further, they found out that actually Okular wouldn’t freeze, but loading these large maps would simply occupy Okular for quite a while, making the user think it crashed.

Naturally the City of Munich wanted this issue fixed. But this use case is rather rare for the voluntary Free Software Developer, as only few user groups, like architects, are actually in the situation of having to deal with such large files, so it was unlikely that this bug would be fixed on a voluntary basis.

Since the city does not have enough developer power to fix all such issues themselves, they looked to KDAB for external support. With our KDE and Qt expertise, we were well-positioned to help. Together we identified that, instead of the suggested busy indicator for Okular the City of Munich wanted, progressive loading would be an even better solution. It allows the user to visually follow the loading process and makes it possible for the user to interact with large files as early as possible. And as the City does not want to maintain a patch that fixes this issue for them locally, we also helped them to get all the patches upstream.

This way all efforts are made available for the architects at the City of Munich and also for the general public. In the same spirit we have fixed numerous issues for the City of Munich all around KDE and Qt. As another example: we brought back extended settings to the Qt print dialogue. This allows the City of Munich to make use of all of the functionalities of their high-tech printer, like sorting, stapling and so on. You can read more about KDAB’s work on this here.

Becoming a distribution implies a lot of responsibility for a public administration and KDAB is proud to offer reliable backup for any administration that decides to follow the Linux, Qt and KDE path.

Afternote: Recent developments mean that the City has decided to revert the migration back to Microsoft by 2020. The good news is that most changes and adjustments they have made are available upstream and other administrations can build their own solutions upon them.

The post The LiMux desktop and the City of Munich appeared first on KDAB.