Planet Qt

At KDAB, we know that consistency is an important aspect of the User Experience – users don’t want to have to learn different ways to achieve the same thing. In the Linux world, there is a major structural pitfall to this: the applications written for Linux come in at least two major technologies –Qt and GTK. Each of these frameworks deeply influences the experience the user has, and in different ways. As you’d expect, the frameworks have their own helper-dialogs e.g. to open or save a file or for printing. This can make it confusing for users, when the apps they use don’t show the same helper-dialogs for common actions.

Most KDE software is written using the Qt library, and within KDE there are lots of attempts to ease the use of GTK applications on Plasma, the KDE desktop. For example, GTK has been styled by members of the KDE community so its applications are visually consistent with the overall KDE look. Nonetheless a major drawback to these efforts remains: helper-dialogs opened from a GTK application are still GTK dialogs and they function differently.

For the user this inconsistency is annoying. Take file handling for example: KDE offers a lot of support to the user. They can define important places – like favorite folders, drives, cloud storage – that allow fast access whenever the user needs to handle files. It follows the KDE idea of navigation through the files, which includes how the user navigates, handling file previews and how the files in a folder are filtered. The file open dialog in GTK is not worse than the KDE one, it is just different. It offers almost the same functionality, but is presented in a way the KDE user is not used to. This can be confusing and frustrating, especially in environments where the user has no choice about the system they have to work with.

Perhaps the best known and most commonly used GTK application is LibreOffice. The limitations it has for KDE users due to the use of GTK dialogs is well known to the LibreOffice community. A lot of effort has already been undertaken to fix this problem. Some ideas even went so far as to migrate large parts of LibreOffice to Qt in order to provide a native feeling for KDE users.

KDAB’s contribution

KDAB is a partner for the City of Munich which has installed open source software for all its employees. It runs a KDE-based desktop called Limux for which KDAB provides support. You can see the full story about our work with Limux and the City of Munich here. The City of Munich provides LibreOffice as its Office Suite, so the employees of the City of Munich asked KDAB if we could find a way to fix the problem described above. After some head scratching, we found a successful solution.

The short version is, we found a way to open the KDE dialogs from within LibreOffice so the user experience is seamless – the employees can just get on with their work without being troubled by the software.

How we did it

The overall effort to port LibreOffice to Qt is a huge undertaking. What’s more, actually maintaining the code afterwards, is even more work. Could we do something else instead? Turns out, there is prior art here – the KDE/Plasma integration for Firefox! As such, it was decided to first investigate whether a similar hack could achieve a good-enough solution for the short-term in LibreOffice: Use the well-maintained GTK LibreOffice code base, style it with the above-mentioned KDE widget style for GTK, and then intercept calls to open the GTK file dialogs and instead show the KDE file dialogs.

The latter part is, sadly, not as easy as one may first believe, since running both GTK and Qt within the same application can lead to nasty side-effects: Accessing the clipboard through two distinct X11/xcb connections, once from GTK and once from Qt, from one and the same application, can easily deadlock for example. To work around this problem, we moved the KDE file dialogs into an external helper process. This approach has already proven successful for Firefox in the past. As such, it was mostly a matter of reimplementing it for the specific needs of LibreOffice. And, once again, the approach yielded good results and the patches for LibreOffice were also accepted upstream!

Although this is a bit more of a hack than we would normally do, it works! And we believe that, overall, this integration approach is less work in the long term than porting LibreOffice fully to Qt and maintaining it alongside the GTK layer. What’s more, as this is an open source project, all of our efforts have been upstreamed and will be available for all LibreOffice users under KDE, not only the employees of the Munich City Council.

The post LibreOffice and Plasma 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.

Gotcha

We use three dds files for our skymaps, irradiance, radiance and specular. If you are trying this on a Mac, you will have to uncompress them or they will not work. Keep the names similar to their compressed version. For example we simply added ‘-16f’ to the filename. So our files would be ‘wobbly_bridge_4k_cube_irradiance’ vs ‘wobbly_bridge_4k-16f_cube_irradiance’ respectively.

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.

Gotcha

If you select Camera and hit F1 to find the import, you will in fact be shown the import for the non-Qt3D Camera. The one you will want is: import Qt3D.Render 2.9

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.

our-roll-up 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.

KDAB’s contribution

How we did it

The post LibreOffice and Plasma appeared first on KDAB.

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.

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();

QRC creation

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.

Gotcha

The necessities

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.

Gotcha

If you select Camera and hit F1 to find the import, you will in fact be shown the import for the non-Qt3D Camera. The one you will want is: import Qt3D.Render 2.9

The sky is the limit

#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);

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.

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

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

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

meetqt_tuautomotive_boston2018_facebook_1200x900_shared-img

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.

Starting with the upcoming Qt Creator 4.7, the Clang Code Model is enabled by default. That’s a great time to look at the differences between our old code model and the new Clang Code Model. But first things first.

History of C/C++ Support in Qt Creator

Since the beginning of Qt Creator the C/C++ support was implemented around a custom C++ frontend (lexer, preprocessor, parser, lookup). The whole support was referred to as the “C/C++ Code Model”, the code model being the collection of language-specific services, for example code completion and semantic highlighting.

Back then the next C++ standard was a long time in the coming (C++0x – C++1x – C++11), the tooling support from Clang was not where it is today and a custom C++ front-end gave us some extra flexibility when it comes to performance, error recovery and support of Qt-specifics. The code model around the custom front-end served us well (and still does) – the appropriate trade-offs between precision and performance were made back then. However, maintaining a custom C++ front-end is not a trivial task, notably so during the interesting times for the company we were part of back then, and with only a few developers on it. With the availability of Clang and its tooling, especially from the point on where it became self-hosting, we did some experiments to base the code model on it – the “Clang Code Model” was born. The experiments looked promising in general, but the stability and performance were a problem from the beginning on, especially when considering all platforms.

Fast forward: today C++ evolves much faster, Clang and its tooling are prospering and we have picked up working on the Clang Code Model.

Status of the Clang Code Model

We believe to have addressed the most severe performance and stability issues by now. With the Clang Code Model you get up to date language support based on libclang 6.0, greatly improved precision and diagnostics.

The first big area we have tackled are the services related to the currently open file, not taking any project or global index information into account yet, which is work in progress. Currently, the following services are implemented with the Clang Code Model:

Code completion
Syntactic and semantic highlighting
Diagnostics with fixits and integrated Clang-Tidy and Clazy checks
Follow Symbol (partly)
Outline of symbols
Tooltips
Renaming of local symbols

For the not yet ported services, the services based on the custom frontend are used. This includes for example indexing, find usages and refactoring.

Due to Clang’s precision the Clang Code Model is inherently slower than the old code model and has lower error recovery capabilities. However, the extra precision and diagnostics will result in less build errors and thus reduce your edit-build-cycle count.

Differences to the old code model

Now what are the visible changes that you can observe as a user?

Updated language support

The Clang Code Model is based on libclang 6.0 and as such it can parse C++17 and more.

Precision

You will immediately notice the improved precision in highlighting and diagnostics.

For example, our custom front-end never validated function calls and thus you would notice these when building. With the Clang Code Model only valid function calls are properly highlighted, whereas invalid ones will be rendered as “Text”, that is, black by default.

Another example is code completion. Items are no longer offered for declarations that are below your completion position, except class members of course. Also, completion of const objects will take the “constness” into account.

Diagnostics

Chances are that you will notice Clang’s diagnostics early on, as they are displayed as inline annotations in the editor. Detailed information is provided by tooltips. Check out for the light bulb at the end of the line, as these indicate the availability of “Fixits”. These are small/local refactoring actions fixing diagnostics.

Of course the diagnostics for the current document are also available in the Issues pane. This behavior can be disabled by using the “Filter by categories” icon in the Issues pane toolbar.

You can set up diagnostic configurations in C++ > Code Model >“Manage…” in the options dialog. The predefined configurations are really a starting point and it is recommended to adapt them to your needs. For example, you could set up a configuration for a specific project.

Note that Clang-Tidy and Clazy checks are integrated, too. Enabling these checks for the Clang Code Model will naturally slow down re-parsing, but depending on your machine and the specific selection of checks this can be a great help. Starting from this version, it is also possible to run Clang-Tidy and Clazy checks for the whole project or a subset of it (Menu: Analyze >“Clang-Tidy and Clazy…”). For example, you could set up a diagnostic configuration for this mode that also enables the expensive checks and run it once in a while.

Code Completion

In general, the completion is more context-sensitive now. For example, completing after “switch (“, “case “, “int foo = ” or after “return ” will put more relevant items to the top of the completion list.

The completion of templated classes and functions is improved. Completion of unique_ptr<>/shared_ptr<> objects and friends works now on all platforms.

Does your code base make use of doxygen comments? Then you will probably be happy to see doxygen comments as part of the completion item, too.

Miscellaneous

Italic arguments in a function call indicate that the function call might modify the argument (“Output Argument” in the text editor settings).

Tooltips resolve “auto” properly and show also doxygen comments.

A visible document is automatically re-parsed if one of its headers is modified, either in an editor or on disk.

Future of C/C++ Support

Given the evolving tooling around C++ it is pretty unlikely that we will go back to a custom front-end.

Given the raise of the Language Server Protocol and the development of clangd, how to proceed from here on? The implementation of an LSP client makes sense for any IDE to also get support for other languages. And we are actively working on that. Having that, it will also help us to evaluate clangd further.

The post Qt Creator’s Clang Code Model appeared first on Qt Blog.

KDAB’s contribution

How we did it

The post LibreOffice and Plasma appeared first on KDAB.

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

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.

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();

QRC creation

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.

Gotcha

The necessities

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.

Gotcha

If you select Camera and hit F1 to find the import, you will in fact be shown the import for the non-Qt3D Camera. The one you will want is: import Qt3D.Render 2.9

The sky is the limit

#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);

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.

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

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

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

Description

Due to a CSRF vulnerability affecting the qute://settings page, it was possible for websites to modify qutebrowser settings. Via settings like editor.command, this possibly allowed websites to execute arbitrary code.

This issue has been assigned CVE-2018-10895.

Affected versions

The issue was introduced in v1.0.0, as …

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

C++ Support

The greatest improvements were again done for our Clang based C++ support. First of all we made the Clang code model the default for Qt Creator 4.7. That is quite a milestone after years of experimenting and developing, so Nikolai has wrapped up the history and current state in a separate blog post. I’ll just summarize some of the most important changes in 4.7 here.

We did another upgrade of the backend to Clang 6.0, which was released this March. This brings all its improvements like new and fixed diagnostics to Qt Creator as well.

The outline pane and dropdown, the locator filter for symbols in the current document, and Follow Symbol inside the current translation unit (meaning current document and its includes) are now based on Clang too.

You can now perform the static checks from Clang-Tidy and Clazy on the whole project or a subset. This is implemented as a new analyzer tool in Debug mode (Analyzer>Clang-Tidy and Clazy). We also improved the settings, and fixed that the static checks had a performance impact on completion.

Note that you can opt-out of using Clang code model by manually disabling the ClangCodeModel plugin in Help>About Plugins (Qt Creator>About Plugins on macOS). That said, it is very important that we get as much feedback as possible at this stage, so please create bugreports for all issues that you find.

QML Support

The QML code model now includes minimal support for user defined enums, which is a new feature in Qt 5.10 and later. Additionally some reformatting errors have been fixed.

Test Integration

If your text cursor in the C++ editor is currently inside a test function, you can directly run that individual test with the new Run Test Under Cursor action. The test integration now also marks the location of failed tests in the editor. For Google Test we added support for filtering.

Other Improvements

The kit options got their own top-level entry in the preferences dialog, which is also the very first one in the list. In the file system view you can now create new folders. By default it now shows folders before files, but you can opt-out to the previous, purely alphabetic sorting by unchecking the option in the filter button menu. In the context menu on file items at various places, for example the projects tree, file system view and open documents list, there is a new item that opens a properties dialog, showing name, path, mime type, permissions and many more properties of the file.

There have been many more improvements and fixes. Please refer to our changes file for a more comprehensive list.

Get Qt Creator 4.7 Beta

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 Beta is also available under Preview>Qt Creator 4.7.0-beta1 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.

Note on Wayland support: Even though stated differently in Johan’s blog post, we explicitly disabled the Wayland platform plugin for Qt Creator 4.7 beta1. It broke too heavily in some setups. We will look into adding it again as an opt-in option after the beta.

The post Qt Creator 4.7 Beta released appeared first on Qt Blog.

KDAB’s contribution

How we did it

The post LibreOffice and Plasma appeared first on KDAB.

The Performance Analyzer

You may have heard about the Performance Analyzer (called “CPU Usage Analyzer” in Qt Creator 4.6 and earlier). It is all about profiling applications using the excellent “perf” tool on Linux. You can use it locally on a Linux-based desktop system or on various embedded devices. perf can record a variety of events that may occur in your application. Among these are cache misses, memory loads, context switches, or the most common one, CPU cycles, which periodically records a stack sample after a number of CPU cycles have passed. The resulting profile shows you what functions in your application take the most CPU cycles. This is the Performance Analyzer’s most prominent use case, at least so far.

Creating trace points

With Qt Creator 4.7 you can also record events for trace points, and if your trace points follow a certain naming convention Qt Creator will know they signify resource allocations or releases. Therefore, by setting trace points on malloc, free, and friends you can trace your application’s heap usage. To help you set up trace points for this use case, Qt Creator packages a shell script you can execute and prompts you to run it. First, open your project and choose the run configuration you want to examine. Then just select the “Create trace points …” button on the Analyzer title bar and you get:

How does it work?

In order for non-privileged users to be able to use the trace points the script has to make the kernel debug and tracing file systems available to all users of the system. You should only do this in controlled environments. The script will generally work for 32bit ARM and 64bit x86 systems. 64bit ARM systems can only accept the trace points if you are using a Linux kernel of version 4.10 or greater. In order to set trace points on 32bit x86 systems you need to have debug symbols for your standard C library available

The script will try to create trace points for any binary called libc.so.6 it finds in /lib. If you have a 64-bit system with additional 32-bit libraries installed, it will try to create trace points for both sub-architectures. It may only succeed for one of them. This is not a problem if your application targets the sub-architecture for which the script succeeded in setting the trace points.

Troubleshooting

If the trace point script fails, you may want to check that your kernel was compiled with the CONFIG_UPROBE_EVENT option enabled. Without this option the kernel does not support user trace points at all. All 32-bit ARM images shipped with Qt for Device Creation have this option enabled from version 5.11 on. Most Linux distributions intended for desktop use enable CONFIG_UPROBE_EVENT by default.

Using trace points for profiling

After creating the trace points, you need to tell Qt Creator to use them for profiling. There is a convenient shortcut for this in the Performance Analyzer Settings. You can access the settings either for your specific project in the “Run” settings in “Projects” mode, or globally from the “Options” in the “Tools” menu. Just select”Use Trace Points”. Then Qt Creator will replace your current event setup with any trace points it finds on the target system, and make sure to record a sample each time a trace point is hit.

After this, you only need to press the “Start” button in the profiler tool bar to profile your application. After the application terminates, Qt Creator collects the profile data and displays it.

Interpreting the data

The easiest way to figure out which pieces of code are wasting a lot of memory is by looking at the flame graph view. In order to get the most meaningful results, choose the “Peak Usage” mode in the top right. This will show you a flame graph sorted by the accumulated amount of memory allocated by the given call chains. Consider this example:

Findings

What you see here is a profile of Qt Creator loading a large QML trace into the QML Profiler. The QML profiler uses a lot of memory when showing large traces. This profile tells us some details about the usage. Among other things this flame graph tells us that:

The models for Timeline, Statistics, and Flame Graph views consume about 43% of the peak memory usage. TimelineTraceManager::appendEvent(…) dispatches the events to the various models and causes the allocations.
Of these, the largest part, 18.9% is for the Timeline range models. The JavaScript, Bindings, and Signal Handling categories are range models. They keep a vector of extra data, with an entry for each such range. You can see the QArrayData::allocate(…) that allocates memory for these vectors.
Rendering the Timeline consumes most of the memory not allocated for the basic models. In particular Timeline::NodeUpdater::run() shows up in all of the other stack traces. This function is responsible for populating the geometry used for rendering the timeline categories. Therefore, QSGGeometry::allocate(…) is what we see as direct cause for the allocations. This also tells us why the QML profiler needs a graphics card with multiple gigabytes of memory to display such traces.

Possible Optimizations

From here, it’s easy to come up with ideas for optimizing the offending functions. We might reconsider if we actually need all the data stored in the various models, or we might temporarily save it to disk while we don’t need it. The overwhelming amount of geometry allocated here also tells us that the threshold for coalescing adjacent events in dense trace might be too low. Finally, we might be able to release the geometry in main memory once we have uploaded it to the GPU.

Tracing Overhead

Profiling each and every malloc() and free() call in your application will result in considerable overhead. The kernel will most likely not be able to keep up and will therefore drop some of the samples. Depending on your specific workload the resulting profile can still give you relevant insights, though. In other words: If your application allocates a huge amount of memory in only a handful of calls to malloc(), while also allocating and releasing small amounts at a high frequency, you might miss the malloc() calls you are interested in because the kernel might drop them. However, if the problematic malloc() calls form a larger percentage of the total number of calls, you are likely to catch at least some of them.

In any case, Qt Creator will present you with absolute numbers for allocations, releases, and peak memory usage. These numbers refer to the samples perf actually reported, and therefore are not totally accurate. Other tools will report different numbers.

Special allocation functions

Furthermore, there are memory allocation functions you cannot use for profiling this way. In particular posix_memalign() does not return the resulting pointer on the stack or in a register. Therefore, we cannot record it with a trace point. Also, custom memory allocators you may use for your application are not handled by the default trace points. For example, the JavaScript heap allocator used by QML will not show up in the profile. For this particular case you can use the QML Profiler, though. Also, there are various drop-in replacements for the standard C allocation functions, for example jemalloc or tcmalloc. If you want to track these, you need to define custom trace points.

Conclusion

Profiling memory usage with Qt Creator’s Performance Analyzer is an easy and fast way to gain important insights about your application’s memory usage. It works out of the box for any Linux targets supported by Qt Creator. You can immediately browse the resulting profile data in an easily accessible GUI, without any further processing or data transfer. Other tools can produce more accurate data. However, for a quick overview of your application’s memory usage the Performance Analyzer is often the best tool.

The post Profiling memory usage on Linux with Qt Creator 4.7 appeared first on Qt Blog.

At the company I’m working at, we’re employing Qt WebChannel for remote access to some of our software. Qt WebChannel was originally designed for interfacing with JavaScript clients, but it’s actually very well suited to interface with any kind of dynamic language.

We’ve created client libraries for a few important languages with as few dependencies as possible: pywebchannel (Python, no dependencies), webchannel.net (.NET/C#, depends on JSON.NET) and webchannel++ (header-only C++14, depends on Niels Lohmann’s JSON library).

Python and .NET are a pretty good match: Their dynamic language features make it possible to use remote methods and properties like they were native. Due to being completely statically typed, C++ makes the interface a little more clunky, although variadic templates help a lot to make it easier to use.

As with the original Qt WebChannel C++ classes, transports are completely user defined. When sensible, a default implementation of a transport is provided.

Long story short, here’s an example of how to use the Python client. It’s designed to talk with the chatserver example of the Qt WebChannel module over a WebSocket. It even supports the asyncio features of Python 3! Relevant excerpt without some of the boilerplate:

async def run(webchannel):
    # Wait for initialized
    await webchannel
    print("Connected.")

    chatserver = webchannel.objects["chatserver"]

    username = None

    async def login():
        nonlocal username
        username = input("Enter your name: ")
        return await chatserver.login(username)

    # Loop until we get a valid username
    while not await login():
        print("Username already taken. Please enter a new one.")

    # Keep the username alive
    chatserver.keepAlive.connect(lambda *args: chatserver.keepAliveResponse(username))

    # Connect to chat signals
    chatserver.newMessage.connect(print_newmessage)
    chatserver.userListChanged.connect(lambda *args: print_newusers(chatserver))

    # Read and send input
    while True:
        msg = await ainput()
        chatserver.sendMessage(username, msg)


print("Connecting...")
loop = asyncio.get_event_loop()
proto = loop.run_until_complete(websockets.client.connect(CHATSERVER_URL, create_protocol=QWebChannelWebSocketProtocol))
loop.run_until_complete(run(proto.webchannel))

pywebchannel can also be used without the async/await syntax and should also be compatible with Python 2.

I would also really like to push the code upstream, but I don’t know when I’ll have the time to spare. Then there’s also the question of how to build and deploy the libraries. Would the qtwebchannel module install to $PYTHONPREFIX? Would it depend on a C# compiler (for which support would have to be added to qmake)?

In any case, I think the client libraries can come in handy and expand the spectrum of application of Qt WebChannel.

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