Injeqt 1.2 and plans for 2.0

Injeqt 1.2 will be the last release of 1.x series. It includes one bugfix (for invalid test results in release mode) and one more feature - get_all_with_type_role method.

I do not have any ideas for new features for Injeqt 2.0. It may mean that it is feature-complete or that my use cases are very simple and not representative for wider audiences. However, for each thing I wanted to add to the library, I have come up with better (and simpler) solution that works best outside of library.

For example, I wanted a Repository feature to automatically add object that are subclasses of given class to another object. In Kadu that would be sublasses of Action added to repository named Actions. Core has a lot of them and most of plugins provides additional ones. After lots of thinking a InjectorRegisteredActions RAII class was created inside of Kadu that takes care of this without any kind of new class annotations.

Here it is:

InjectorRegisteredActions::InjectorRegisteredActions(
Actions &actions,
injeqt::injector &injector) : m_actions{actions}
{
for (auto const &o : injector.get_all_with_type_role(ACTION))
{
auto action = qobject_cast<ActionDescription *>(o);
if (action && m_actions.insert(action))
m_registeredActions.push_back(action);
}
}

InjectorRegisteredActions::~InjectorRegisteredActions()
{
for (auto const &a : m_registeredActions)
m_actions.remove(a);
}

It can be easily turned to template, and it will be as soon as need arise.

As I can think of any new features, Injeqt 2.0 will be more of API improvement release. There are things I need to do:

  • get rid of instantiate_all_with_type_role()
  • get rid of just-introduced get_all_with_type_role()
  • rename type role to tag
  • replace it with a types() method that will return all types with their tag information
  • then use all the data to implement instantiate_all_with_type_role() and get_all_with_type_role() outside of library or as free helper functions (with better names, of course)
  • get rid of version namespace, it is not needed as nobody will ever use it
  • check if ranges library will be useful (injeqt uses lots of containers and algorithms)

Qt Creator 4.2.2 released

butterfly

The spring has arrived, so we took our brooms and swept the bugs from under the carpets and out of the door.

We meticulously noted down all the classes, orders, families, species, and other details of what we found and removed, which you can look up in our spring cleaning log.

Get Qt Creator 4.2.2

The opensource version is available on the Qt download page, and you find commercially licensed packages on the Qt Account Portal. Qt Creator 4.2.2 is also available through an update in the online installer. Please post issues in our bug tracker. You can also find us on IRC on #qt-creator on chat.freenode.net, and on the Qt Creator mailing list.

The post Qt Creator 4.2.2 released appeared first on Qt Blog.

Five days and counting

It is five days left until foss-north 2017, so it is high time to get your ticket! Please notice that tickets can be bought all the way until the night of the 25th (Tuesday), but catering is only included is you get your ticket on the 24th (Monday), so help a poor organizer and get your tickets as soon as possible!

And just to reiterate what’s on the menu. This is a full day conference with two tracks and many interesting speakers from many projects, including Debian, Wikimedia, KDE, systemd, PulseAudio, Nextcloud, PostgreSQL, OpenRISC, flatpak, AsteroidOS and more.

Last year, over 30% of the tickets was sold in the last 48h. This year, we cannot provide catering for the ones buying tickets the last 24h, so hopefully the peak will come earlier. For now, we have 93 persons on the visiting list, but there are chairs for 100 more!

Please update your Qt Online Installer’s Maintenance Tool

We are about to change the domain used in Qt Online Installations. If you are using an old version of Maintenance Tool, that is 2.0.3 or older, now is a good time to update it to version 2.0.5. So please run ‘Update components’ and your Qt installation will continue working without errors. The MaintenanceTool should be updated by May 5th 2017. After this you may encounter errors when using Maintenance Tool. Note that version 2.0.4 does not need the update as there are no references to the domain that is about to be shut down.

The post Please update your Qt Online Installer’s Maintenance Tool appeared first on Qt Blog.

Second qutebrowser crowdfunding launched!

Like last year, I'd love to spend my summer holidays working full-time on qutebrowser again!

This is why I started another crowdfunding - with the goal of finally implementing the new config system. See the Kickstarter campaign for details.

In a nutshell, that means:

  • There's a separate (optional) config file, which will never be touched by qutebrowser, and is much better suited for people who prefer editing their config by hand and/or managing it in a VCS like git.
  • Many new possibilities for the config, like setting the backend (QtWebKit/QtWebEngine), or other things which need to be available early (like disabling canvas reading).
  • The ability to set many settings for individual domains - such as enabling JavaScript individually (like NoScript), or setting user-stylesheets for some pages (like Stylish).
  • Much more powerful configuration (in Python).
  • Many other configuration bugs and quirks which will be fixed along the way.

Like last year, you can get qutebrowser stickers and t-shirts by contributing to the crowdfunding. Also, expect to see regular updates on this blog again!

Multithreaded Programming with Future & Promise

by Ben Lau [Qt Champion 2016] (Qt Blog)

This is a guest post by 2016 Qt Champion Ben Lau.

Ben has a long history with Qt, and many interesting projects on GitHub.

Here’s an idea from him on making multithreading simpler in some cases.

The Basics

Multithreading programming may not be difficult at the first glance. You have to pay attention to your shared data to avoid race conditions/deadlocks. So you learn mutex and semaphore and do it carefully. The result works perfectly on your machine.

But one day, your program hangs. You spend an hour to trace out the problem and find out the order of code execution is not same as your expectation. So you add a few mode condition checking and fix the problem.

After a few week of development, the program is getting more complicated. And it begins to crash randomly. This time even after a day you still can’t figure out what is wrong and admit that it is totally out of control.

Does that sound like a familiar story? It is not rare to find complaints about random crashes/hangs due to misuse of a thread. Is it really difficult to write multithreaded programs?

The answer is yes and no. It depends on your software requirement and architecture.

In this article, it is going to introduce a lock-free multithreaded programming method by using QtConcurrent and AsyncFuture. These make multithreaded programming easier.

Let’s take an example. The code below shows an asynchronous ImageReader class. The readImageWorker function will be executed on another thread that won’t block the UI. QFuture represents the result of computation and reports the status change.

class ImageReader : public QObject {
public:
    QFuture<QImage> read(const QString& fileName);
};

QFuture<QImage> ImageReader::read(const QString &fileName)
{
    auto readImageWorker = [](const QString &fileName) {
        QImage image;
        image.load(fileName);
        return image;
    };
    return QtConcurrent::run(readImageWorker, fileName);
}

Example of use

ImageReader reader;

QFuture future = reader.read(INPUT);

QFutureWatcher *watcher = new QFutureWatcher();

connect(watcher, &QFutureWatcher::finished,
 [=]() {
 setImage(future.result());
 });

watcher->setFuture(future);

Multithreaded programming with QtConcurrent is pretty easy. It just takes an input, then produce an output later. QtConcurrent handles all of the low-level threading primitives.

But it is limited to the condition that the concurrent function does not access shared data with other threads. If that happens, it may still need a lock in order to maintain a critical session. That will fall back to the old traditional way.

Make it support Image caching

The above example is quite an ideal case. And of course, a real world problem is usually not that simple. Let’s change the requirement – Make it support image caching.

QFuture ImageReader::read(const QString &fileName)
 {
 auto readImageWorker = [](const QString &fileName) {
 QImage image;
 image.load(fileName);
 return image;
 };

QFuture future = QtConcurrent::run(readImageWorker, fileName);

QFutureWatcher *watcher = new QFutureWatcher(this);

auto updateCache = [=]() {
 m_cache[fileName] = future.result();
 watcher->deleteLater();
 };

connect(watcher, &QFutureWatcher::finished, updateCache);
 watcher->setFuture(future);
 return future;
 }

The class declaration:

class ImageReader : public QObject {
 public:
 bool isCached(const QString& fileName) const;
 QImage readCache(const QString& fileName) const;
 QFuture read(const QString& fileName);
 private:
 QMap<QString,QImage> m_cache;
 };
 bool ImageReader::isCached(const QString &fileName) const
 {
 return m_cache.contains(fileName);
 }

QImage ImageReader::readCache(const QString &fileName) const
 {
 return m_cache[fileName];
 }

Before getting an image, you have to query is the cache available:

if (reader.isCached(INPUT)) {
 setImage(reader.readCache(INPUT));
 return;
 }
 QFuture future = reader.read(INPUT);

This solution works, but the API is not ideal. Because it would violate the “Tell, don’t ask” principle. The best way is to combine readCache() and read() into a single function that always returns a QFuture object. But there is a problem, QFuture/QtConcurrent can only obtain a result from a thread. It is quite odd to start a thread but the data is already available. To get rid of this problem, we need a 3rd party library.

AsyncFuture

AsyncFuture is a C++ library that could converts a signal into a QFuture type and uses it like a Promise object in Javascript. It provides a unified interface for asynchronous and concurrent tasks. The library only contains a single header file, so that it is very easy to bundle in your source tree. Or you may install it by qpm.

Project Site:
https://github.com/benlau/asyncfuture

Let’s rewrite the above function with AsyncFuture:

QFuture ImageReader::read(const QString &fileName)
 {
 if (m_cache.contains(fileName)) {
 // Cache hit. Return an already finished QFuture object with the image
 auto defer = AsyncFuture::deferred();
 defer.complete(m_cache[fileName]);
 return defer.future();
 }

if (m_futures.contains(fileName)) {
 // It is loading. Return the running QFuture
 return m_futures[fileName];
 }

auto readImageWorker = [](const QString &fileName) {
 QImage image;
 image.load(fileName);
 return image;
 };

auto updateCache = [=](QImage result) {
 m_cache[fileName] = result;
 m_futures.remove(fileName);
 return result;
 };

QFuture future = AsyncFuture::observe(QtConcurrent::run(readImageWorker, fileName)).context(this, updateCache).future();
 m_futures[fileName] = future;
 return future;
 }

This time it is almost perfect. The deferred object provides an interface to complete/cancel a QFuture manually. That could replace readCache() by returning an already finished future object.

Moreover, it has added a new feature to avoid duplicated image reading. In case you have made requests to load the same image twice before it is cached, the original design would start two threads which are totally wasting CPU power. This version solves it by keeping all the running future in a future pool and return that future for duplicated read.

Make the example more complicated

Currently the example is very simple. Let’s try to make it more complicated.

Requirements:

  1. Add a readScaled(fileName, size) function that returns an image which is scaled to specific size
  2. Code reuse is a must
  3. The scaling must be done in another thread to emulate a high CPU usage function
  4. Load cached image if available
  5. But scaled image do not need to keep in cache

The most optimistic solution is to make use of the result of read() directly. That mean you have to create a thread that depends on the result of another thread. That is a bit hard to get it works with only QtConcurrent and probably it needs to use a lock. But it can be easy to be done with AsyncFuture’s future chaining feature.

QFuture ImageReader::readScaled(const QString &fileName, const QSize &size)
 {
 auto scaleImageWorker = [=](QImage input) {
 return input.scaled(size);
 };
 auto callback = [=](QImage result) {
 return QtConcurrent::run(scaleImageWorker, result);
 };
 QFuture input = read(fileName);
 QFuture output = AsyncFuture::observe(input).context(this, callback).future();
 return output;
 }

First of all, it calls read() function to obtain an image from QFuture. It doesn’t care about the caching mechanism as it is already handled by the read() function.

Then it creates a new future object to represent the whole work flow of the chain:

QFuture output = AsyncFuture::observe(input).context(this, callback).future();
                                                                     ^^^^^^^^^

A chain begins with a observe() function, then followed by an observer function to bind the callback to the observed future, and that will create a new future object to represent the result of the callback.

auto callback = [=](QImage result) {
 return QtConcurrent::run(scaleImageWorker, result);
 };

You may wonder if it is alright to run another worker function within the callback function. In fact, this is a feature of AsyncFuture. It provides a chainable API that works like a Promise object in JavaScript. If the callback returns a QFuture object, it will be added to the chain. Then the final output future will depend on the returned future. Therefore, the output future is in fact represents the result of read() , callback() and scaleImageWorker(). The flow could be visualised by this diagram:

sequence-diagram_promises

Diagram: The workflow of readScaled() – it shows how it uses a single QFuture to represent the result of a multiple steps task.

Conclusion

Using QtConcurrent without sharing data between threads could make multithreaed programming easier because it doesn’t need to manage an access lock. But real world problems are usually more complicated. A task may not be able to complete without interaction from other threads. In this case, it may still need an access lock to protect critical session. But once you have used it, it will fall back to the old traditional way, and probably it may get the same problem mentioned at the beginning.

In this article an alternative solution is presented: Use Concurrent API together with asynchronous callback then chain them into a sequence by a promise like API. It works by breaking down a task into multiple steps. Whanever a concurrent function seeks for extra information from another thread, it should just terminate itself and pass the control back to the main thread. So that it doesn’t need an access lock that may raise issues like deadlocks and race conditions.

The whole workflow could be represented by a QFuture object, a unified interface for all kind of asynchronous workflow.

However, this doesn’t mean we get rid of locks completely. They are still necessary for some scenarios. So choose your solution case by case.

The post Multithreaded Programming with Future & Promise appeared first on Qt Blog.

Uncovering 32 Qt best practices at compile time with clazy

In a previous blog post we introduced clazy, a clang plugin which makes the compiler understand Qt semantics, allowing you to get compile-time warnings about Qt best practices ranging from unneeded memory allocations to misuse of API, including fix-its for automatic refactoring.

Today we’ll do a round-up and present the checks related to connect statements, Qt containers (including QString) and misc Qt facilities.

Connects

1. old-style-connect

Finds connect() statements still using the old SIGNAL()/SLOT() syntax. The Qt …

The post Uncovering 32 Qt best practices at compile time with clazy appeared first on KDAB.

Qt World Summit 2017 Early Bird Tickets Now Available!

qtws_berlin

Build for Tomorrow
Deliver Today

The 14th annual Qt World Summit is returning to Berlin! Be sure to join the Qt event of the year taking place 10-12 of October at bcc, Berlin Congress Center.

Get ready for five tracks of inspiration as we bring the latest details on what is happening with Qt. From innovative demos to expert presentations, inspiring Speakers and the coolest applications imaginable. Whether you’re looking to take a deep technical dive or seeking business insights, we have something for everyone at this year’s Qt World Summit

Designed for business people and developers alike, the Qt event of the year has something for everyone who is envisioning, innovating and implementing tomorrow’s devices and applications.

At Qt World Summit in Berlin, get on the inside track on how software is driving the future of IoT. Learn the secrets to creating user experiences that stand out and are a pleasure to use – and a pleasure to build. See how you can maximize development performance for embedded, desktop, and mobile devices. Be a part of the biggest Qt event in 2017 – check out all the latest demos and Qt applications, meet with other Qt users and developers from all around the world and across multiple industries.

Tickets available now

register_early

Head over to the Qt World Summit website and click Register to make sure you are among the first to get your tickets.

Qt Contributors’ take note

This year we will not hold a separate Qt Contributors’ Summit, but we are inviting all Qt Contributors to a pre-event before Qt World Summit.

So mark your calenders, October 9th and 10th are the days, and the place is bcc.

To register, go to the Qt World Summit website and click Register, Qt Contributors’ Days are included in the ticket list with a nominal fee.


The post Qt World Summit 2017 Early Bird Tickets Now Available! appeared first on Qt Blog.

Disabling narrowing conversions in signal/slot connections

A small new feature that I have added to Qt 5.8 is the possibility of disabling narrowing conversions in the new-style QObject::connect statement. In this short blog post I would like to share with you why I thought this was useful and therefore implemented it.

The problem

Since Qt 5.0, the new-style, PMF-based (pointer to member function-based) QObject::connect will check at compile time if the signal’s signature is compatible with the slot’s one.

For instance, let’s consider these two …

The post Disabling narrowing conversions in signal/slot connections appeared first on KDAB.

ArcGIS Runtime SDK 100.0 by Esri is here

by Eric Bader, Product Manager, Esri [Qt Customer] (Qt Blog)

In 100.0, Qt developers have even more capabilities for adding mapping and geographic analysis to native apps than ever before. 3D geographic visualization, 2D vector tiled basemap support, enriched error handling in the API, and additional geoprocessing tools are just a few of the new highlights.

Esri is proud to announce the commercial release of ArcGIS Runtime SDK 100.0 for Qt. This is quite a revolutionary and innovative release for ArcGIS developers. The API architecture is continuing to evolve for those of you who are looking to build great native applications for a wide range of devices and platforms!

In addition, Qt developers have more app deployment and design options. These include the following:

  • Support for writing C++ apps that can target all platforms, including macOS, iOS and Android. Esri is committed to providing as many developer options for Qt developers as possible!
  • Support for separating your QML and C++ business logic. Enabling support for this design pattern frees up the Qt developer to adopt best-design practices while writing great GIS apps!

A few of the highlighted features include, but are definitely not limited to:

  • 3D visualization – On desktop platforms, 3D has been brought to the ArcGIS Runtime for native app development. Build 3D scenes with raster, tiled and vector data sets including 3D specific symbology for enhancing viaualization of your geographic data. 

esri-globe-300

  • Maps and scenes – The Map object has been split out from the view that displays it, to represent the model or viewmodelcomponent in a Model-View-Controller (MVC) or Model-View-ViewModel (MVVM) architecture. This same design is also implemented for Scene objects.

maps-and-scenes-300

  • Military symbology API – On desktop platforms, the API and workflow for using Military symbology has been greatly simplified in this release.

military-symbology-api-200x200

  • Go offline – To make things easy for you, the APIs for common operations such as editing, searching, geocoding or routing are the same whether you are online or offline.

There are too many capabilities to describe in this short post, so go check it out yourself. You’ll be surprised by how much you can achieve with ArcGIS Runtime SDK 100.0 for Qt.

We invite you all to download v100 and get started today!

 

 

The post ArcGIS Runtime SDK 100.0 by Esri is here appeared first on Qt Blog.

Qt 5.9 Beta Released

I am pleased to announce that Qt 5.9 Beta is now released. Convenient binary installers are available for trying out the cool new features coming in Qt 5.9. With this release we are adjusting the release process to make it easier for users to check out the upcoming release conveniently using the online installer. 

Qt 5.9, scheduled to be released at the end of May, completes the work started with Qt 5.7 and 5.8 to take Qt 5 to the next level. Compared to Qt 5.6 LTS we have added a lot of new features such as fully leveraging C++11, a new configuration system, new graphics architecture, a new set of Qt Quick Controls, convenient support for Wayland multi-process, Qt 3D, and many, many more. We have also worked hard to improve the performance to be even better across the board, but especially on embedded hardware. Our target is that a Qt application running on Qt 5.9 not only has more features to choose from, but also runs with better performance and increased maturity compared to an earlier version of Qt.

With Qt 5.9 we are slightly adjusting the release process of Qt. After the Beta that was released today we will push out multiple new Beta N releases using the online installer. With the new approach it is easier than before for users to test the features and provide feedback (via bugreports.qt.io). During the beta phase we expect to have new Beta N releases with 1-2 weeks intervals. When the maturity has increased sufficiently we will create a release candidate and then the final release of Qt 5.9.0. These will be made available directly via the online installer, we are not planning publish separate blogs for the subsequent beta releases and release candidates. In addition to binaries, source packages of each beta release are of course also available for those who prefer to build themselves.

I hope many of you will install the Qt 5.9 Beta release(s), test and provide us your feedback to complete Qt 5.9. For any issues you may find, please submit a detailed bug report to bugreports.qt.io (please remember to mention which beta you found the issue with). You are also welcome to join the discussions in the Qt Project mailing listsdeveloper forums and of course we encourage you to contribute to Qt. You may also want to check out the list of most important new features in Qt 5.9, as well as the new features in Qt 5.8 and new features in Qt 5.7 – in case you are still using Qt 5.6 LTS.

If you do not yet have the Qt online installer, get it from the Qt Account or from the Qt Download page.

The post Qt 5.9 Beta Released appeared first on Qt Blog.

QStringView Diaries: The Eagle Has Landed

After two months of intensive reviews, discussions, fixes, and stripping down the initial commit, feature by feature, to make it acceptable, I am happy to announce that the first QStringView commits have landed in what will eventually become Qt 5.10. Even the docs are already on-line.

This is a good time to briefly recapitulate what QStringView is all about.

continue reading

The post QStringView Diaries: The Eagle Has Landed appeared first on KDAB.

Swift is Changing

Due to potential confusion between the Swift XMPP Client and Apple’s Swift programming language, we’re adopting a new name for Swift. Read on for more information and a link to our new website!

It’s has now been over 2 years since the Swift XMPP client became part of Isode’s product set and during that time we’ve seen significant changes to the product and the market within which it operates.

One of the biggest non-technical changes was Apple’s decision (in 2014) to name it’s new programming language “Swift” and its simultaneous decision to adopt an icon for this language with a great many similarities to the one used by our XMPP Client.

From a marketing perspective the possible confusion between our XMPP Client and Apple’s programming language is clearly a cause for concern. We’ve been pondering what moves we should make to protect Swift’s identity as an XMPP client for some time.

I am pleased to announce therefore that we’ll be adopting a new name and new look for the Swift XMPP client which, from today, will be known as Jolly Brisk!™ a name we’ve chosen to reflect the speed of the client and its connection to Isode Ltd, a British company.

We’re still in the early days of establishing a new identity for Jolly Brisk! and we need your help.

We’ve started on the new website which shows off our new corporate identity and some screenshots of our client. We’d appreciate your feedback on this new and radical change.

We expect to fully adopt the new identity with Swift 4.0, which will be launched as Jolly Brisk!™ 1.0.

Getting more out of Qt Quick with OpenVG

by Andy Nichols (nezticle) (Qt Blog)

In Qt 5.9 is now possible to render Qt Quick applications with OpenVG when using hardware that supports it. This is made possible by a new scene graph adaptation that uses EGL and OpenVG to render Qt Quick scenes.  When using Qt for Device Creation, it means that it now be possible to run with graphics hardware acceleration on some devices where today only software rendering is available.

OpenVG Logo

So what is OpenVG (or if you already know: Seriously… OpenVG?)

OpenVG is an API for hardware accelerated 2D vector graphics.  The API exposes the ability to draw and shade paths and images in an accelerated manner.  The OpenVG 1.1 standard was developed by the Khronos Group and is implemented by vector GPU vendors.  The reason for the tone of sarcasm in my sub-heading and why I am sure there will be more than a few readers eye-rolling is that OpenVG has been around for quite some time.  The latest update of the OpenVG 1.1 standard was released in 2008. In addition the Khronos working group for OpenVG has since disbanded likely meaning there will not be any further updates.

This is also not the first time that Qt has supported OpenVG in one way or another.  In Qt 4 there was an OpenGL paint engine that enabled QPainter commands to be rendered using the OpenVG API. I do not wish to revive that code, but rather choose to limit usage of the OpenVG API to a smaller subset to accelerate the rendering of Qt Quick applications.

So why OpenVG now?

Qt runs on many embedded devices, but to get the most benefit out of Qt Quick has so far required at least OpenGL 2.0 support. At the same time customers want to use Qt Quick on their low-end embedded devices lacking OpenGL-capable GPUs.  So first we introduced the Software adaptation, previously known as the Qt Quick 2D Renderer. See our previous posts here and here. There is however an in-between where hardware has a GPU supporting OpenVG 1.1 but not OpenGL 2.0.  OpenVG is a good match for accelerating the rendering of Qt Quick because most features can be enabled, leading to better performance on hardware that has OpenVG-capable GPU.

A few examples of system-on-chips with this configuration are the NXP iMX6 SoloLite, and Vybrid VF5xxR chips which both use the GC355 Vector GPUs enabling OpenVG.  The OpenVG working group may no longer be actively working on the standard itself, but SoC vendors are still releasing on hardware that supports OpenVG.

How does it perform?

The expected behavior for the OpenVG adaptation is that it fills the space between OpenGL and Software rendering.  With hardware that supports both OpenGL and OpenVG, expect the OpenGL renderer to outperform OpenVG as OpenGL gives more opportunities for optimisation.  If you test the OpenVG adaptation on a Raspberry Pi you will see that default OpenGL renderer will do significantly more before dropping below 60 FPS.

How can I make use of the OpenVG adaptation?

To use the OpenVG backend you will need to build Qt with support for it.  In Qt 5.9 we have re-added a test for OpenVG support which will enable the feature in Qt Quick.  Once you have a suitable build of Qt deployed to your target device you will need to run your application with a platform plugin that supports EGL (EGLFS or MinimalEGL).  Then if you set the environment variable QT_QUICK_BACKEND=openvg your Qt Quick applications will create OpenVG capable EGL surfaces, and render using OpenVG commands. For more information, see the scenegraph adaptation section at the snapshot documentation site.

Limitations

Like the Software adaptation, the OpenVG adaptation comes with some limitations due to the lack of 3D and Shader Effects.  It is not possible to use QML components that depend on OpenGL or Shader Effects directly. That means that Qt Quick modules like Particles and Graphical Effects are not available.  If your application works with the Software adaption, it will work better with the OpenVG backend with hardware capable of using it.

The EGLFS platform plugin also introduces some limitations.  When using EGLFS platform with Qt for Device Creation you may have become accustom to having a mouse cursor and support for multiple child windows.  Despite the platform plugins name (EGL Fullscreen) it is a bit naughty and does use OpenGL for a few things. Specifically composing multiple windows and the mouse cursor.  If you use EGLFS on a platform without OpenGL though, these features are not available.  In a shipping device this usually isn’t an issue.  It can be annoying if you don’t expect it during the development phase.  Funny enough we had a very similar limitation with the OpenVG paint engine in Qt 4 with QWS.

Conclusions

In the embedded space there is a need to make use of any available resources. This adaptation is just one more way that Qt is helping fill that need.  I hope that this adaptation will make some of your device creation efforts easier so that you can spend more time making cool products with Qt.  Thanks for reading and keep on hacking.

The post Getting more out of Qt Quick with OpenVG appeared first on Qt Blog.

Qt Creator 4.3 Beta released

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

Qt Quick Designer with integrated code editor

Qt Quick

Qt Quick Designer now integrates a QML code editor. This allows you to use views like the Properties editor and the Navigator also for text based editing. When you use the split view, you directly see the effects of what you are doing. The graphical editor got support for adding items and tab bar to stacked containers like StackedLayout and SwipeView, a tool bar with common actions, and support for HiDPI displays.

When you profile your Qt Quick application with the QML Profiler, you see performance information now also directly in the QML code editor. And the profiler itself received many performance improvements as well.

CMake

If you use Qt Creator with CMake 3.7 or later, we now use the server-mode that was added to CMake 3.7 for the benefit of IDEs. It provides much better information about the project structure, include paths, and more, than what we could parse from the generators and Makefile before. As a result you also see products and targets in the project tree and can build them individually.

Regardless of CMake version we added header files to the project tree, even if they are not listed explicitly in the project files. You now can also import existing builds of a CMake project, like we already provide for QMake based projects, which sets up a kit with the information found in the CMake cache from the build, and registers new toolchains and Qt versions as needed.

C++

Sometimes code is interpreted differently in different contexts. A file can be used by different (sub-)projects with different defines, or be included in the context of C, C++, Objective-C, or Objective-C++. You already could choose a different project in the dialog behind the little # in the editor toolbar. We moved this to a separate dropdown menu in the editor toolbar, and added the choice of language as well.

If you are up for a bit of experimentation, enable the ClangRefactoring plugin. It adds preliminary support for clang-query to Advanced Find and uses Clang for the local renaming refactoring.

Mobile Development

If you use Qt Creator for iOS development, you can now choose the developer team and provisioning profile used for signing. This overrides the default that QMake chooses and any settings you have in your project files.

Unfortunately the newest version 25.3.1 of the Android SDK does not work with current Qt and Qt Creator versions. Some essential tools that we relied on have changed. We are working on fixing the issue. You can track it through QTCREATORBUG-17814. For the time being please stay at Android SDK 25.2.5.

CDB Support

The CDB debugging support that we ship with our packages now uses a Python based pretty printing backend. That has multiple advantages. The debugger starts much faster, and the unification of pretty printing between GDB, LLDB and CDB brings more and better pretty printers to Qt Creator’s CDB support.

Other Improvements

There have been many more improvements, which are described in more detail in our change log.

Get Qt Creator 4.3 Beta

The opensource version is available on the Qt download page, and you find commercially licensed packages on the Qt Account Portal. 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: We now provide 64-bit offline installers for Windows.

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

foss-north speaker line-up

I am extremely pleased to have confirmed the entire speaker line-up for foss north 2017. This will be a really good year!

Trying to put together something like this is really hard – you want the best speakers, but you also want a mix of local and international, various technologies, various viewpoints and much, much more. For 2017 we will have open hardware and open software, KDE and Gnome, web and embedded, tech talks and processes, and so on.

The foss north conference is a great excuse to come visit Gothenburg in the spring. Apparently, Sweden’s wildest city!

WebGL streaming in a Raspberry PI Zero W

A week ago I received my Raspberry Pi Zero W to play a bit with some IoT device. The specs of this small device computer are the following:

  • 1GHz, single-core CPU
  • 512MB RAM
  • Mini HDMI and USB On-The-Go ports
  • Micro USB power
  • HAT-compatible 40-pin header
  • Composite video and reset headers
  • CSI camera connector

But the interesting part comes with the connectivity:

  • 802.11 b/g/n wireless LAN
  • Bluetooth 4.1
  • Bluetooth Low Energy (BLE)

And especially from one of the hidden features that allows one to use the device as a headless device and connect using SSH over USB adding the following line to config.txt:
dtoverlay=dwc2
And modifying the file cmdline.txt to add:
modules-load=dwc2,g_ether

remember to create a file called ssh to enable SSH access to your Raspberry Pi. There are plenty tutorials over the Internet showing this! 😀

To build a Qt version for the device you can follow this guide.
In the following screen shot, we can see the calqlatr example running directly on the Raspberry Pi:

clocks_pi_zero

One of the use cases which comes to my mind using this device and this feature is being able to create portable presentations and show them on any computer without the need of installing new software.

presentation_pi_zero

For the presentation, I used the qml-presentation-system (link).

More use cases could be:

  • Application showcase.
  • Custom text editor for taking your notes everywhere.

Please comment if you have other ideas or use cases.

The post WebGL streaming in a Raspberry PI Zero W appeared first on Qt Blog.

Boosting performance with shader binary caching in Qt 5.9

Now that Qt 5.9 is getting closer, let’s take a look at a minor but immensely useful improvement to the basic OpenGL enablers that form the foundation of Qt Quick and the optional OpenGL-based rendering path of QPainter.

Those looking at the documentation snapshots for 5.9 may have already come across some new functions in the venerable QOpenGLShaderProgram. What is more, most internal usages in Qt have been switched over to the new API. What does this mean in practice?

As explained here, such shader programs will attempt to cache the program binaries on disk using GL_ARB_get_program_binary or the standard equivalents in OpenGL ES 3.0. When no support is provided by the driver, the behavior is equivalent to the non-cached case. The files are stored in the global or per-process cache location, whichever is writable. The result is a nice boost in performance when a program is created with the same shader sources next time.

How big is the improvement? It varies. Some drivers have already been doing some sort of caching for the past couple of years, while some others have similar features in the pipeline. However, the gains turn out to be quite significant in practice on devices that are out in the field right now:

image2016-11-21-152420

Do not read too much into the actual numbers. What is important is the difference between Qt 5.8 and 5.9. Also, a simple Qt Quick or GL-backed QPainter scene will definitely not use 10 programs, but as complexity grows, with Qt Graphical Effects and custom ShaderEffect items entering the picture, getting similar improvements does not look far fetched anymore.

In fact we gain something even on systems that employ shader caching already. Therefore every application’s startup and view switching times are expected to benefit with Qt 5.9 – without having to change anything.

Applications that use QOpenGLShaderProgram on their own can usually switch to the cacheable function variants by just changing the name in the function call. The change have to be a conscious decision, though, since some of the APIs change semantics when program binaries are used. Most notably, QOpenGLShader, addShader(), and removeShader() are incompatible with the program-level caching since they rely on individual shader compilation.

That’s it for now, stay tuned for more posts about exciting upcoming Qt 5.9 and 5.10 features.

The post Boosting performance with shader binary caching in Qt 5.9 appeared first on Qt Blog.

Safety critical drawing with OpenGL SC

Bringing software into a safety critical environment can be tricky, especially when using the complex APIs needed for modern 3D graphics. That’s what makes OpenGL SC (Safety Critical) so important: it bridges the gap between beautiful displays and functional safety, while trying to remain as close to existing embedded standards that we all know and love. OpenGL SC will only become more prevalent in embedded graphics work as industries increasingly try to merge safety conscious methodologies with user-friendly interfaces. continue reading

The post Safety critical drawing with OpenGL SC appeared first on KDAB.

Device Tailored Compositors with Qt Wayland at CLAAS E-Systems

by Andreas Cord-Landwehr [(PhD), Development Engineer at CLAAS E-Systems] (Qt Blog)

Software Development in Agriculture

Have you heard about software in cars that run on embedded devices? Do you think that creating such software might be challenging? Well, welcome to a complete new world of complexity, welcome to the world of agriculture machines! For many years, automatic steering (on fields), terminals to control the complex mechanical operations of a self-driving 16 ton combine harvester on a soft ground, and self-optimization systems to optimize any tiny bit of your harvester, are key demands from customers. I, myself, am working at CLAAS E-Systems, the electronics and software department within the CLAAS group. Our group is well known for being among the leading manufacturers for combine harvesters, tractors and forage harvesters.

The main human machine interaction interface on such machines, besides the driving joystick and the throttle pedal, are tablet like control terminals appended at the end of the driver’s arm rest. It is my daily job to bring awesome looking and user friendly interfaces together with safety regulations and put the results onto such terminals. Considering today’s demands on these terminals, we are approaching what one is used from a typical Linux desktop system: For example, one can think about different applications for steering, controlling the machine functionality, or the entertainment system. Such separations into different processes not only increase robustness. In a field with heavy safety regulations, clear separations of scopes and interactions they are a virtue to decrease effort spent on safety assurance.

Window Compositing using Wayland

Naturally, the composition of the different windows of separated processes into a seamless UI is the task of a window compositing system. From the desktop world we know the good old X.org server that today is slowly replaced by much more modern Wayland compositors. In the mobile and embedded world its successor already took over and Wayland is the default choice when considering a window compositor. Unlike for X.org, there are different implementations of the Wayland window compositing protocol. Best known, there is the Weston compositor, the actual reference implementation of the Wayland protocol. On top of it, driven by the demands in the automotive industry, there is also the IVI protocol abstraction layer. IVI provides a very small compositor interface with the primal goal of exchangeability and compatibility, for which your BSP (board support package) supplier usually has a compatible compositor to offer. And IVI often works well, specifically when you have a UI with only limited window dynamics or animations, like a static display of windows as it is the typical case for radio control and climate control windows in a car. But if you want to add fancy window animations or if you have a certain complex UI and gesture workflow in mind, the IVI protocol drastically shows its limits. Taking a step back and considering to extend the Weston compositor, however, would bring you into the complex world of working at the heart of one of your most crucial software components in an unfamiliar environment.

Qt Wayland Compositor

Recently with the Qt 5.8 release, the Qt Wayland Compositor Framework started to become a viable new alternative. It not only provides the Qt Quick API that allows you to easily create a compositor from scratch with just a few lines of declarative QML code. In particular, it allows you to change your work assumptions when thinking about a compositor: Since the whole compositor is created in Qt Quick and the complex surface interaction and Wayland protocol logic is well hidden, it is possible for “just” a Qt Quick developer with basic Wayland understanding to create a compositor from scratch. The big benefit therein lies in the point that such a developer is well trained in using Qt Quick for creating awesome user interactions with great looking UIs. For creating a compositor that presents all available windows in a swipeable way, a Qt Quick developer just uses a ListView, adds the windows and it’s done. Now think about how long a Wayland expert would need for this task and how challenging it would be to do some rapid prototyping for such a compositor in the other case.

The power of the QtWayland compositor framework thus is not only that it provides a nice and lean API to use but that it shifts the task of creating a Wayland compositor from the very specialized field of Wayland engineers to the field of Qt Quick/Qt developers. It allows you to focus just on creating the best interaction and UI for your customer, hence what really counts. If you are eager to try it out, just look at the examples shipped with the framework. Maybe you are also interested in my recent talk at FOSDEM ’17 in which I showed how simple it is to create a compositor from scratch.

The post Device Tailored Compositors with Qt Wayland at CLAAS E-Systems appeared first on Qt Blog.

QtMob: Qt mobile application development becomes easier

by Marco Piccolino [QtMob community manager] (Qt Blog)

As a professional mobile application developer you probably already know by now how awesome Qt makes most of your daily job.

Yet, things like finding that useful (but undocumented) qmake option, deciding upon the application architecture to use for your next project, implementing native extensions on Android and iOS, checking whether a suitable library for your component already exists, might prove quite difficult if you are on your own.

The forums, IRC and mailing lists are great places to start from for one-shot questions, but sometimes you need a dedicated environment with peers where you can have a more focused and ongoing discussion about your daily matters. Here is where QtMob comes in.

QtMob is a global community of professional Qt mobile application developers that are willing to share their pains, knowledge and resources.

QtMob is a Slack chat, so that you can leverage all the goodies that modern-day, computer-mediated conversation has to offer.

It is a tool that you can open in the morning while sipping your coffee/tea, to likely find a bunch of fresh new mobile-related resources that someone just posted.

It sports a good mix of professional Qt mobile app developers, relatively fresh Qt users who love being on the cutting edge and sharing what they just discovered, Qt veterans who are looking for a smooth transition to newer topics like mobile and Quick, members of the QtCompany who want a direct channel with a group of mobile devs for feedback, as well as professionals from companies which have invested in Qt on mobile to provide middleware and services to application developers.

Members come from industries as diverse as game development, medical software, geographic informations systems, you name it. That’s just as diverse as the Qt users spectrum.

QtMob is also a place for collaborations, where members get feedback about new packages and tools they are offering or plan to offer to the community (among others, Cutehacks’ qpm package manager, Qt Champion Benlau’s many utility libraries, Grecko’s SortFilterProxyModel qml wrapper, Esri’s ArcGIS SDK, VPlay’s mobile SDK or just recruit consultants for their next project.

QtMob is the right place to start an in-depth discussion about strategies to prevent memory warnings on iOS, choosing the right push notifications component, talking about Qt and Redux, implementing CI, making .pro changes to support your build, or just shouting your frustation in the #bottomlesspit channel.

Here are a few first impressions from a community member, Sassan from Teheran:

“After joining this group I was able to ask questions, and there was always someone who responded quickly, either with the solution or the reason why it was not possible yet to achieve what I needed. A question may initiate discussions about the topic, and you’ll end up knowing much more than what you asked for, which is good because it will save you lots of time not doing the wrong things others have tried before. Your question may end up as a feature request on the Qt bugtracker.

After joining this group I was able to know about the latest technologies, packages, related softwares, etc around Qt. It’s really nice to know for example the time you spend to release your app can be reduced 5 times by using tools people discuss about here… and that’s just an example.

After joining this group I had the chance to know about the latest up-to-date documents (pdfs, videos, tutorials, etc.) people create about coding in Qt.

After joining this group I had the chance to meet so many nice people, many of whom spend part of their time to contribute to this open source project.

After joining this group I learned about best practices for doing things I already knew how to do, but which I can now do better.”

We recently celebrated user #100 (while I write the count is 130), Jeff Galbraith from iMirror: a good example of using Qt for mobile in innovative settings like fitting rooms. But QtMob members use cases are just so many…

Come along and see, it’s free!

The only requirement: be willing to give at least as much as you get, in whatever form is best suited to your level of experience and job constraints.

http://slackin.qtmob.org/

The post QtMob: Qt mobile application development becomes easier appeared first on Qt Blog.

Swift and Google Summer of Code 2017

It’s Google Summer of Code time again! Swift is participating in GSOC2017 under the banner of the XMPP Standards Foundation and we’ve posted a range of project ideas covering Swift and Swiften on the XSF wiki. Read on for more information.

As reported in a post on the XMPP Standards Foundation blog, the XSF has once again been accepted as one of the Open Source organizations participating in Google Summer of Code.

We’ve listed some "potential ideas for Swift and Swiften GSOC projects on the XMPP Wiki so, if you’re interested in participating as a GSOC student this year, please take a look.

If any of these projects are of interest, or if you have ideas of your own you’d like to propose, then please join the swift@rooms.swift.im chat room to discuss GSOC and ask questions. We’ve had some great experiences with previous GSOC projects and we’re very much looking forward to working with students this summer.

Cutelyst 1.5.0 released, I18N and HTTPS built-in

Cutelyst the C++/Qt web framework just got a new stable release.

Right after last release Matthias Fehring made another important contribution adding support for internationalization in Cutelyst, you can now have your Grantlee templates properly translated depending on user setting.

Then on IRC an user asked if Cutelyst-WSGI had HTTPS support, which it didn't, you could enable HTTPS (as I do) using NGINX in front of your application or using uwsgi, but of course having that build-in Cutelyst-WSGI is a lot more convenient especially since his use would be for embedded devices.

Cutelyst-WSGI also got support for --umask, --pidfile, --pidfile2 and --stop that will send a signal to stop the instance based on the pidfile provided, better documentation. Fixes for respawning and cheaping workers, and since I have it now on production of all my web applications FastCGI got some critical fixes.

The cutelyst command was updated to use WSGI library to work on Windows and OSX without requiring uwsgi, making development easier.

www.cutelyst.org got Cutelyst logo, and an updated CMlyst version, though the site still looks ugly... .

Download here: https://github.com/cutelyst/cutelyst/archive/v1.5.0.tar.gz .

Have fun! .

QNanoPainter with Qt 5.8 (and QSGRenderNode)

QNanoPainter recently gained initial support for QSGRenderNode which is a new public class available starting from Qt 5.8. What this means is that instead of rendering through FBO using QQuickFramebufferObject so, OpenGL drawing is done directly into Qt Quick Scene Graph. And as a QQuickItem somewhere in the middle of scene, not just underlay/overlay for the scene which was already possible before Qt 5.8 using beforeRendering & afterRendering.

Below is a video running QNanoPainter tester app on MacBook Pro with 16 unique QQuickItems using QSGRenderNode mode:



So should you enable QNANO_USE_RENDERNODE with your custom QNanoPainter items?

  • There is a potential performance gain for not rendering through FBO. Especially if your UI contains many custom items and/or you resize items, QSGRenderNode may give more gains as FBO resizing can be costly.
  • However, based on my testing with few different Android devices the performance difference seems pretty small, just few percentages. Maybe with some less performant embedded platforms which are bad with FBOs there is a bigger difference.
  • With QQuickFramebufferObject, rendering is always clipped to FBO size, so item clip true/false property doesn’t have any effect. With QSGRenderNode such clipping doesn’t automatically happen, instead each item can freely paint anywhere outside its rect. Whether this is pros or cons is up to your use case, but good to note anyway.
  • With QSGRenderNode, standard QQuickItem features (position, rotation, clipping, scaling etc.) need to be implemented customly. QNanoPainter doesn’t (yet) fully support clipping of QML item tree so if you have several clip regions and/or rotate these items, clipping doesn’t necessarily behave as expected when using QNANO_USE_RENDERNODE.
  • When your item doesn’t need to be repainted, just re-rendered, it’s more performant to render the FBO. So if your items don’t change often it might be better not to enable QNANO_USE_RENDERNODE.

So with all above said, QNANO_USE_RENDERNODE is not currently enabled by default even when building with Qt 5.8. But that might change somewhere in future if gains seem worth it. For now please upgrade your QNanoPainter library and test how it works for you.

Just three days left…

The call for papers for foss-north 2017 ends on Sunday. That means that you only have three days to…

  • … get a chance to visit Gothenburg, Sweden, the most sociable city in the world!
  • … speak in front of a great audience of 220 people (if we sell all the tickets – get your’s here).
  • … listen to other awesome speakers. Right now we’ve confirmed Lydia Pintscher, Lennart Poettering, Knut Yrvin and Jos Poortvliet. (There will be more awesome speakers announced when the call for papers is over).

So what are you waiting for – submit your talk proposal and join us at foss-north 2017!

What do I do if a slot is not invoked?

All Qt developers have asked themselves at least once in their careers: “why isn’t my slot invoked?” (I’ve asked myself that question many, many times).

There are a number of reasons why a connection may fail to be properly set up, and ultimately cause our slot not to be invoked. This blog post is a practical series of checks to help you debug these sorts of issues.

0. Was the slot really not invoked?

First and foremost, are we really …

The post What do I do if a slot is not invoked? appeared first on KDAB.

Provisioning OpenStreetMap providers in QtLocation

Background

This post is to provide some clarification on a behavioral change we had to introduce with Qt 5.6.2 to the QtLocation‘s OpenStreetMap plug-in. The related change seems to have generated some confusion, so here’s the full story.

The OSM plug-in used to work with hard-coded tile server URLs for the various map types offered therein. The tiles for the main (street) map type and the satellite map type, which are possibly the two most used maps, were previously sourced from open.mapquest.com. In July 2016, MapQuest discontinued this service. As a result, all deployed QtLocation OSM plug-ins for the Qt versions up to 5.6.1 and 5.7.0 suddenly began to provide tiles without map content. Instead the tiles contained an invitation to visit the MapQuest website and buy some services as shown below.

MapQuest ceasing open access

The dreadful sight from the MapViewer prior to Qt5.6.2

Solution

Clearly not being able to afford another such situation, we decided to fix this by adding one level of indirection. Now the OSM plug-in will fetch, for each map type, a provider definition file hosted at maps-redirect.qt.io. The format of this file is fairly similar to what others solutions use (e.g. TileJSON), with small differences needed for our specific use case. The format is documented in this file (starting from line 195). This solution makes it possible to change the tile source for specific map types, if this becomes necessary again, without the need to upgrade Qt or to rebuild the application.

These providers can also be temporarily disabled on the server side, by setting the property Enabled to false. This might happen in cases like the above mentioned where the service delivers bogus tiles and a replacement hasn’t been found yet. The plug-in also ships with a hard-coded backup for connectivity reasons.

Unfortunately, at this stage we haven’t been able to find an open access satellite imagery provider that would provide sufficiently high resolution data. As a result, the OSM plug-ins initially still offers seven map types (the satellite map type is still there) but, at the present, they become six as soon as the map provider definition file for the satellite type is parsed since it currently contains Enabled = false.

The screenshots below demonstrate the difference:

Mapviewer before and after resolution

The MapViewer MapType menu before provider initialization (left) and after (right)

While this approach solves the encountered problem, it might be an undesirable behavior for some. Therefore, we added two options to disable this behavior. The first option is to set the plug-in parameter osm.mapping.providersrepository.disabled to true. This instructs the plug-in to not attempt any remote provider file fetching, but to just use the hard-coded values. Since this alone would bring the initial problem back, there is also another plug-in parameter that may come in handy. The osm.mapping.providersrepository.address can be used to override the default value of http://maps-redirect.qt.io/osm/5.6/, for 5.6.2 and 5.7.1, and http://maps-redirect.qt.io/osm/5.8/ for 5.8.0 and later releases. Developers can point the plug-in to an alternative URL containing the provider definition files for street, satellite, cycle, transit, night-transit, terrain and hiking. Even local URLs starting with file:/// or qrc:/ are possible, which means that the provider definition files can be shipped with the application.

As a last note, please bear in mind that this solution is still not 100% fail safe. The mapping service is still offered by third parties with whom The Qt Company has no contractual relationship. If a robust solution is needed, using one of the commercial services that we support through one of the other shipped plug-ins should be considered.

The post Provisioning OpenStreetMap providers in QtLocation appeared first on Qt Blog.