Ci vediamo a QtDay 2017?

With an apology to English-speaking audiences 🙂

Anche quest’anno KDAB partecipa a QtDay, la conferenza italiana interamente dedicata a Qt. Giunta oramai alla sua sesta edizione, QtDay continua a crescere. Quest’anno QtDay si articola in 3 giorni: il primo dedicato a un training su QML, seguito da due giorni di conferenza vera e propria.

Durante la conferenza terrò due interventi:

  • Venerdì 23 giugno parteciperò ad una tavola rotonda sul come contribuire allo sviluppo di Qt;
  • Sabato 24 giugno

The post Ci vediamo a QtDay 2017? appeared first on KDAB.

Functional Safety with the Qt Safe Renderer

I am pleased to announce a new approach for inclusion of functional safety critical user interface elements in Qt based systems. The new Qt Safe Renderer makes it easy to create safety critical systems that also have a rich graphical user interface. Industries such as automotive, medical and industrial automation, where Qt is the leading UI framework, can now satisfy safety critical requirements with Qt easier than before.

For those who are not yet familiar with our approach to functional safety please check the earlier blog post about functional safety and a blog post on how to create certified systems with Qt.

To create a certified system, the safety critical features must be separated from the other parts of the system. The safety critical functionality can be separated, for example, by running in own memory protected processes with a certified Real-Time Operating System (RTOS). This leaves two parts that need to be addressed in a safety critical system:

  • Certified tooling to produce the UI design workflow
  • Designing, writing and certifying the safety-critical code

The new Qt Safe Renderer solves both of these by providing tooling to design safety critical UI items and dedicated software to reliably render the these elements in a Qt based safety critical system.

The Qt Safe Renderer tooling makes it easy to add safety critical UI elements to Qt based safety critical systems. Adding safety critical UI elements, such as telltales or other indicators, is very simple using Qt’s drag-and-drop visual design tools. Qt even comes with a comprehensive set of ISO standard icons for warnings and other indicators, all readily accessible from the visual design tool. The visual design tool integration allows modifications to the safety critical UI elements without needing to change any of the certified software components.

Qt Safe Renderer Design Tool

Image 1: Adding safety critical visual elements to a Qt application is convenient with the provided visual design tools.

ISO Icon Browser

Image 2: Qt provides a wide selection of ISO standard warning and other icons and a convenient tool to use these in the Qt application.

After you have added the safety critical UI elements to the application, it is time to build. A new tool extracts the safety critical UI elements from the UI providing the layout and images of the safety critical parts to the safety certified renderer component. The tool also removes the safety critical parts from the main Qt UI. When the system is running, no matter what happens in the main UI, the safe rendering system ensures that the safety critical parts continue to operate uninterrupted.

safe_pic_3

Image 3: A digital instrument cluster leveraging Qt Safe Renderer can be certified according to ISO 26262 ASIL B.

With Qt and the Qt Safe Renderer it is possible to create many different kinds of certified systems. While our initial focus is on automotive digital cockpits this solution is also applicable to medical and industrial automation systems. ISO 26262, IEC 61508 or IEC 62304 are some of the applicable standards that we are working to certify the new Qt Safe Renderer for.

Qt Safe Renderer works with Qt 5.9 and Creator 4.3, or later versions. For the target RTOS we are supporting INTEGRITY and QNX. On the silicon side we are supporting the NXP iMX6 and NVIDIA Tegra X1 with plans to to add support for Qualcomm Snapdragon 820 and Renesas H3. We can support alternative RTOS and processors on an as needed basis.

The Qt Safe Renderer and related tooling will become available as an add-on to the commercially licensed Qt.

Contact us to learn more and discuss your safety related needs in more detail.

The post Functional Safety with the Qt Safe Renderer appeared first on Qt Blog.

Built with Qt: Episode I – Feeding Automation

We create #BuiltwithQt cases so that people who are new to Qt can get an idea of what Qt is used for and for people who already know Qt to see what is possible. In the past 12 months, we have created a lot of videos — not only customer cases, but talks and demos from events.

The automation industry spans from home & building through to service & industrial automation and even scales up to ship automation. Qt is being used in everywhere within the automation industry and there are a wide range of customers such as M2I, Ulstein and CELOS who are using Qt. Automation is catching fire and here are some additional examples of companies using Qt in the automation space that may entice your interest.

Let’s indulge:

LG Electronics, is a leader in smart kitchen appliances as well as consumer electronics, and recently showcased their Alexa-running smart refrigerator built with Qt and using WebOS, which is also the OS they are using in their Smart TVs.

smart-home

N&W Global Vending is a worldwide leader in manufacturing specialized food and beverage vending machines using Qt, NXP i.MX6 and Witekio services to brew a perfect hot beverage of your choice. You can even check the weather and see a Twitter feed on the machine’s HMI while you are waiting for your coffee — a need I did not know I had.

CELOS simplified machine automation with a network process for consistent management, documentation and visualization of an order, process and machine data–all built with Qt. Operational automation, energy saving, ERP/POS systems? No problem.

Qt is truly everywhere and we’ll be at the NRA Show 2017 booth #6875 showcasing what’s possible with Qt Quick Controls 2  with Venture/Vest! Join us and contact us to learn more.

 

 

The post Built with Qt: Episode I – Feeding Automation appeared first on Qt Blog.

Training in Foss Compliance

On June 23rd 2017, there’s a new, one day training in our Berlin facility, this time in German.

Training in FOSS Compliance will be available, in English, in Berlin and other locations later this year. More on that below, in English. Meanwhile, since our first open-enrolment training to help you with the complex issues around compliance is in German…….

Der Begriff Corporate Compliance ist seit einigen Jahren in den Fokus der Öffentlichkeit gerückt, aber wenige Unternehmen wissen bislang um die

The post Training in Foss Compliance appeared first on KDAB.

INTEGRITY RTOS Support in Qt 5.9 LTS

I am pleased to confirm that Qt 5.9 LTS officially supports the INTEGRITY Real-Time Operating System (RTOS) from Green Hills Software. INTEGRITY was initially supported with Qt 4.8 and will again be supported from Qt 5.9 onwards. The interest in running Qt on INTEGRITY has been customer driven, primarily from Automotive for use in safety certified Instrument Clusters, but also from other industry sectors.

One might ask why is it important to support INTEGRITY for Qt? Why is the leading cross-platform application and UI framework needed in RTOS applications? Aren’t these the ones so deeply buried into our infrastructure, that you almost never notice when you come across one? Well, yes and no. It is true that most of the RTOS applications are still done without any UI, let alone a fancy and interactive graphical user interface. But the number of those RTOS applications that require an advanced GUI framework to meet the user expectation is growing fast, along with the demand to run Qt on an RTOS that provides high degree of safety and security. Other embedded operating systems, such as embedded Linux, are not sufficient when it comes to their real-time capability, reliability, security and certified operations essential for certain industries such as automotive, medical, aerospace and industrial automation.

Qt 5.9 LTS for INTEGRITY is covered by our excellent technical support for all existing Qt for INTEGRITY license holders. All the most important modules are available, for example: Qt Core, Qt Network, Qt GUI, Qt Quick, Qt Qml, Qt Quick Controls 2 and Qt 3D. Initially we are supporting NXP i.MX6 and NVIDIA Tegra X1 hardware. Other hardware, such as Intel Apollo Lake can also be used, and we intend to continue adding support for new hardware with subsequent Qt releases. The following video shows Qt 5.9 LTS based digital instrument cluster running on top of INTEGRITY RTOS with NXP i.MX6 and NVIDIA Tegra X1.

Leveraging the Qt framework with INTEGRITY RTOS enables an easy way of adding state-of-the-art graphical user interfaces to security and safety critical systems. It is easier to certify the product to comply with the requirements of for example the automotive or medical industries when the solution is built on top of an RTOS that is already certified for that industry domain. We see many industries, for example medical, automotive, industrial automation, aerospace and defense, directly benefiting from now being able to leverage Qt for INTEGRITY. The in-built capabilities of the INTEGRITY RTOS platform allow the Qt framework to run in such a way that it does not interfere with the real-time operation of the system. This simplifies creation of safety critical systems and enables certifying the Qt based system to standards for functional safety such as IEC 61508, ISO 26262 and IEC 62304.

Green Hills INTEGRITY is not only a certified RTOS, but also provides a real-time hypervisor, INTEGRITY Multivisor, allowing guest OSes such as Linux to run on the same SoC as the safety critical RTOS. This simplifies building complex systems such as digital cockpits. The following video shows Qt Automotive Suite running on top of Linux as well as a Qt-based instrument cluster running on the INTEGRITY RTOS – both on the same Intel Apollo Lake SoC leveraging INTEGRITY secure virtualisation.

If you have not yet considered leveraging Qt for your next safety-critical project, I recommend taking a deeper look. Our sales, consultants and support are available to guide you through the evaluation process. If you have any questions, we are very happy to discuss more on how Qt meets the needs of your next product – please contact us.

The post INTEGRITY RTOS Support in Qt 5.9 LTS appeared first on Qt Blog.

Fixing a flaky test – how hard can it be?

Flaky tests are a pain point for any reasonable continuous integration system. And by flaky I refer to tests that sometimes pass and sometimes fail. Lately I’ve been bothered by a lack of data and metrics when it comes to discussions around the topic of flaky tests (it pops up regularly on the Qt development mailing list). It’s a hot topic because it influences our productivity, many randomly failing tests slow everyone down.

Metrics

While we worked a lot on our testing infrastructure, a good way of gathering metrics was lacking. For a while we tried building a custom website, but it wasn’t really maintained, so it slowly died.
For a completely unrelated project, I started running influxdb and grafana on a server. Yes, that’s Qt’s new and shiny benchmark metrics infrastructure. I recently gained some experience with these tools, therefore I decided to log data from Coin.

As a first step logging all failing tests seemed like a good idea. I have a feeling that it has already paid off big time, we now have top lists of flaky and failing tests.

Grafana showing a list of flaky tests

I haven’t done as much C++ work lately as I’d have liked to. And I really felt like spending a bit of time on fixing one or two issues. Where to start? I picked the top candidate off of the list of failing tests. Most often failing and blocking integrations was a test called TouchMouse (written by yours truly, in a past life, and enhanced by others). After looking at the data, it was clear that it was only failing on macOS. Not great for me, my more powerful machine is running Linux. Could I avoid booting up my old, old Mac Mini? My medium old Mac Pro had just died and replacement is still on its way…

Picking up the TouchMouse Test

Let’s open the test’s cpp file to get a feel for the test:

...
// ------------------------- Mouse move to mouseArea1
QTest::mouseMove(window.data(), p1);

QVERIFY(enterSpy1.count() == 1);
QVERIFY(mouseArea1->hovered());
QVERIFY(!mouseArea2->hovered());

// ------------------------- Touch click on mouseArea1
QTest::touchEvent(window.data(), device).press(0, p1, window.data());

QCOMPARE(enterSpy1.count(), 1);
QCOMPARE(enterSpy2.count(), 0);
QVERIFY(mouseArea1->pressed());
QVERIFY(mouseArea1->hovered());
QVERIFY(!mouseArea2->hovered());

QTest::touchEvent(window.data(), device).release(0, p1, window.data());
QVERIFY(clickSpy1.count() == 1);
QVERIFY(mouseArea1->hovered());
QVERIFY(!mouseArea2->hovered());

// ------------------------- Touch click on mouseArea2
if (QGuiApplication::platformName().compare(QLatin1String("xcb"), Qt::CaseInsensitive) == 0)
    QSKIP("hover can be momentarily inconsistent on X11, depending on timing of flushFrameSynchronousEvents with touch and mouse movements (QTBUG-55350)");

QTest::touchEvent(window.data(), device).press(0, p2, window.data());

QVERIFY(mouseArea1->hovered());
QVERIFY(mouseArea2->hovered());
QVERIFY(mouseArea2->pressed());
QCOMPARE(enterSpy1.count(), 1);
QCOMPARE(enterSpy2.count(), 1);

QTest::touchEvent(window.data(), device).release(0, p2, window.data());

QVERIFY(clickSpy2.count() == 1);
QVERIFY(mouseArea1->hovered());
QVERIFY(!mouseArea2->hovered());
QCOMPARE(exitSpy1.count(), 0);
QCOMPARE(exitSpy2.count(), 1);
...

Did you spot it too? Yeah, we skip the test on xcb… now what happens if I comment that out? Let’s run it on Linux for the fun of it.

In the past year I switched to fish as my main shell, that allows me to write while and for loops, without having to read the manual. I never managed to just write them when using bash, but now we’re really getting side-tracked…

set i 0; while
    ./tst_touchmouse hoverEnabled
    set i (math $i+1)
    echo $i
end

is how I run the test in a loop with a nice counter. Good luck getting out of there, pressing ctrl-c at random intervals helps eventually. And wow, the issue can be reproduced immediately (after removing the QSKIP which simply ends the test otherwise).

Understanding the issue

Glancing at the code in QQuickMouseArea, I saw that we have logging code in there, so I opened ~/.config/QtProject/qtlogging.ini and added:

[Rules]
qt.quick.hover.trace=true

Logging for the win! There were three scenarios (see the bug report for details). Sometimes the first MouseArea would get “unhovered”, sometimes not.
I got a nice backtrace by cheating a bit: the extra “unhover” event was in mouse area 1… if only I could break when that happens… I’m weak at writing conditional breakpoints. Let me add a small snippet that will help breaking in the right place in QQuickMouseArea’s code instead:

void QQuickMouseArea::setHovered(bool h)
{
...
    if (objectName() == "mouseArea1" && !h) {
        // break point here
        qDebug() << "mouseArea1 got unhovered";
    }
...
}

Do not forget to set the objectName in QML, otherwise this won’t work. And observe that flushFrameSynchronousEvents runs at regular but indeterministic intervals. Uhhh… that could explain the flakyness. Re-run and see different traces. And for good measure, add one more debug line into QQuickWindowPrivate::flushFrameSynchronousEvents.

...
if (!q->mouseGrabberItem() && !lastMousePosition.isNull() && dirtyItemList) {
    bool accepted = false;
    bool delivered = deliverHoverEvent(contentItem, lastMousePosition, lastMousePosition, QGuiApplication::keyboardModifiers(), 0, accepted);
    if (!delivered)
        clearHover(); // take care of any exits
    qDebug() << Q_FUNC_INFO << "delivered artificial hover: " << delivered << lastMousePosition;
}

We see who’s making this test non-deterministic. Let’s check if there’s a bug report for this… JIRA instantly shows QTBUG-55350 as first hit when I copy “hoverEnabled” into the search field. Suddenly the day was over and I had other business to mind.

Fixing the flaky test

Scene cut; next morning. After breakfast and walking to work while it was snowing (on the 10th of May), it’s back to debugging.
I had the idea that I could comment out some of the test verification and see if everything else is in order. To my dismay, I quickly saw, that something was still off. The second mouse area in the test would suddenly receive hover events after a touch release. This didn’t make sense because we never move the mouse there. Therefore the hover event must be triggered by a touch event. But after a touch release?

At this point, it was fairly easy to spot. The code that sends “pretend” hover events was doing something funny: sending a hover event after a touch release (through flushFrameSynchronousEvents, thus randomly timing dependent). Resetting the variable that keeps track of the last mouse position fixed the problem. That way no more fake events for touch releases are delivered. Suddenly the test completely worked and also on Linux/XCB where it was skipped before. More test coverage enabled and one bug down left a happy developer.
The patch went in and we should have the worst offender removed. I can’t wait to see how the metrics develop over time. I’m sure there’ll be something else coming up again. But now we have metrics to battle it 😉

The post Fixing a flaky test – how hard can it be? appeared first on Qt Blog.

Introducing Long Term Support for Qt 5.9

We are pleased to announce that Qt 5.9 will be a Long Term Supported (LTS) release. We have done a lot of improvements to Qt since the previous, Qt 5.6 LTS, and to maximize the benefits for our users we will make Qt 5.9 an LTS release. There will be several Qt 5.9.x patch level releases created during the next three years – also after the next Qt 5.x releases become available. Commercial licensees eligible for technical support will also be able to submit support requests during the whole LTS period.

Since the release of Qt 5.6, our previous LTS release, a huge amount of improvements has been added to Qt. We have done significant work on improving performance, added multiple important new features, and fixed thousands of bugs. Qt 5.9 LTS is a fantastic product that offers substantial improvements over Qt 5.6 LTS. To make it possible for all our users to benefit from these, we will be providing Long Term Support for Qt 5.9.

As with Qt 5.6 LTS, we will be using a phased approach to content in patch level releases for Qt 5.9 LTS. During the first 6 months after release day, an LTS release receives a lot of fixes, including low-priority ones. Then the LTS release enters a ‘strict’ phase where only critical bugs and security issues are addressed. This will ensure the stability of the LTS releases. During the final year of an LTS release the commit policy is ‘very strict’, at which phase we only address severe security issues.

For all new projects, we strongly recommend using Qt 5.9 LTS. The upcoming Qt 5.9 LTS will be supported alongside with the earlier Qt 5.6 LTS release, which still allows the use of the old C++98 compilers. As already noted above, Qt 5.9 LTS offers lots of performance improvements as well as a vast amount of other improvements and bug fixes that are not included into Qt 5.6 LTS. Currently, Qt 5.6 LTS is in the ‘strict’ phase where it only receives selected critical fixes and next it is moving into the ‘very strict’ phase. During this final phase, Qt 5.6 LTS will receive important security fixes only.

According to our LTS promise, we guarantee that Qt 5.9 LTS will be supported for three years via standard support, after which additional extended support can be purchased. During this time, even though following Qt releases (5.10 onwards) are already out, Qt 5.9 LTS will receive patch releases providing bug fixes and security updates. For an LTS release, the amount of patch releases will be higher than non-LTS releases of Qt and we aim to provide these throughout the LTS period. In addition to security fixes, error corrections and improvements provided by the LTS patch releases, we may also add support for new operating system and compiler versions to an LTS release of Qt, when feasible. It should be noted that the deprecated modules and technology preview modules are not subject to the LTS.

Qt 5.9 Beta releases are already available via the online installer, check it out if you have not yet done so. If you do not have the Qt online installer yet, please get it from the Qt Account or the Qt downloads page. We are working hard to further fix and polish it with the target of having the Qt 5.9.0 final out around the end of May 2017.

The post Introducing Long Term Support for Qt 5.9 appeared first on Qt Blog.

Cutelyst benchmarks on TechEmpower round 14

The new TechEmpower benchmarks results are finally out, round 14 took almost 6 months to be ready, and while a more frequent testing is desirable this gave us plenty of time to improve things.

Last round a bug was crashing our threaded benchmarks (which wasted time restarting), besides having that bug fixed the most notably changes that improved our performance were:

  • Use of a custom Epoll even dispatcher instead of default glib one (the tests without epoll in it's name are using the default glib)
  • jemalloc, this brought the coolest boost, you just need link to it (or use LD_PRELOAD) and memory allocation magically get's faster (around 20% for the tests)
  • CPU affinity that helps the scheduler to keep each thread/process pinned to a CPU core.
  • SO_REUSEPORT which on Linux helps to get connections evenly distributed among each thread/process
  •  Several code optimizations thanks to perf

I'm very glad with our results, Cutelyst managed to stay with the top performers which really pays off all the hard work, it also provide us with good numbers to show for people interested in.

Check it out https://www.techempower.com/benchmarks/

Ci vediamo alla Italian C++ Conference 2017?

(English speaking? Keep reading!)

Il prossimo Giugno parteciperò all’Italian C++ Conference 2017, la più importante conferenza italiana sul C++, sponsorizzata da KDAB.

L’evento è gratuito e si rivolge tanto ai programmatori esperti di C++ quanto a chi voglia avvicinarsi a questo linguaggio. L’edizione di quest’anno prevede due tracce, di cui una completamente in inglese, con ospiti internazionali d’eccezione: Phil Nash, Jens Weller, Bartosz Milewski e Dietmar Kühl.

L’appuntamento è per Sabato 17 …

The post Ci vediamo alla Italian C++ Conference 2017? appeared first on KDAB.

Corso di Qt/QML per Embedded a Milano, settembre 2017

KDAB è lieta di annunciare una data italiana per il corso Programmazione Qt/QML per sistemi embedded, che si svolgerà a Milano dal 12 al 14 settembre 2017.

Qt è un application framework moderno e ricco di funzionalità, utilizzato per realizzare applicazioni cross-platform per sistemi embedded, mobile e desktop. Qt è usato da oltre 800.000 sviluppatori in tutto il mondo per creare interfacce di domotica e home automation; sistemi di in-vehicle infotainment (IVI); pannelli di controllo industriale; applicazioni desktop …

The post Corso di Qt/QML per Embedded a Milano, settembre 2017 appeared first on KDAB.

WeAreDevelopers Conference App – Open Source & Live Now!

This week, the biggest developers conference in Europe is held in Vienna: the WeAreDevelopers Conference 2017. V-Play is joining this conference and to make the conference even better, we have developed an open-source conference app for it!

You can download it now from the app stores:

itunes_download_link google_play_badge-1

You can also download the app on Github and use the code in your own apps. So you can use this app as the basis for your own conference app. Or just use the source code to learn the best-practices we used in the app:

github_logo

What’s Inside the We Are Developers Conference App

What can you do with the conference app?

  • Browse the conference schedule.
  • See detailed information for all talks and speakers.
  • Manage your personal schedule by adding talks to your favorites.
  • Connect with other conference participants, chat and become friends.
  • Get notified of upcoming favorited sessions with push notifications.
  • Full-text search of all speakers & talks.
  • Get rewards with gamification elements: attend talks & start the app often to get to the leaderboard top.
  • Customize the UI and switch between different native styles and colors.

Here are some screenshots from the app for Android & iOS:

wearedevelopers-androidwearedevelopers-ios

How We Developed the Conference App

We used the Qt World Summit Conference App Template that is part of the V-Play SDK as a basis, which looks like this:

native-navigation-ios-and-android

Having the UI and native look & feel for iOS & Android already in place, we only had some minor tweaks left to finish the app:

  • Get the conference data (talks + speakers list) by scraping the WeAreDevelopers website. This task took actually most of the time. 😉
  • Change the theme of the app to reflect the conference colors & style from the website.
  • Add new content like the venue and about page.
  • Create the app in the V-Play Game Network backend to get access to leaderboards, chat and push notifications (when a new chat message or friend invite is received).
  • Write the app store description & create an app icon.

The whole process from start until publishing in the app stores took about 16 hours.

giphy

You’ll be across the finish line in no time!

Conference App Highlights

These are some of our favorite app features:

Simulate Other Platforms at Runtime

You can change the colors & even simulate another platform within your app! Just browse to the settings screen:
wearedevelopers-settings
You can set the theme to iOS on an Android device and vice versa, which is pretty cool for testing what the app looks like on another platform. During development, this saves a lot of time because you can test how your app looks like on all platforms on your Desktop PC!

Gamification

You get points when you open the app and attend talks. There is a leaderboard with the most active conference attendees, and you can connect with these: by sending friend invites and in-app chat messages. This functionality is available with V-Play Game Network and V-Play Multiplayer and takes less than 50 lines of code to integrate!

So you can use gamification functionality also in your V-Play based apps. Gamification features are retention boosters, that’s why we recommend to add it to “normal apps” too and not only games.

Hidden Gems

Here are some of the smaller app features:

  • When the conference is happening, you will see a “Scroll to Now” button that jumps straight to the correct day & time. Convenient, right? :)
  • You get a push notification 15 minutes before your favorited talk starts. You can also disable these notifications in the settings.
  • Images of the speakers are cached after the first network attempt. On conferences, network connection is usually restricted – with this caching mechanism you can even see the speakers images when your phone is offline.

100% Cross-Platform App: Single Code Base

With a single source code, the app looks native on iOS & Android. This means you get:

  • A navigation drawer on Android & bottom tab navigation
  • On iOS you have a swipe-back gesture to navigate back to the last page, on Android the back button is used
  • Native UI elements like tabs, switches, buttons for each platform
  • Native page push/pop animations for each platform

To get this native look & feel, you don’t need to write any platform-specific code. It’s 100% the same source code for both iOS & Android!

The full source code of the app is only ~2,900 lines of code. The app contains 13 pages/screens, which is an average of just 223 loc per page. Quite an impressive featureset for this little source code, right?! If you wonder why so little code is needed: that’s the power of QML and the V-Play app components. For a detailed app comparison of V-Play with other frameworks like React or Xamarin, see the PropertyCross project here.

Meet Us at the Conference!

If you’re attending WeAreDevelopers Conference 2017 and want to find out more about cross-platform development with V-Play, let us know when you want to meet!

Meet the V-Play Team at WeAreDevelopers 2017!

If you’d like to meet at an after-show event, just contact us here!

 

 

More Posts like This

 

How to Make Cross-Platform Mobile Apps with Qt – V-Play Apps

How to Make a Qt app

Release 2.9.2: Qt World Summit 2016 App Showcase and New App Components

Conference App Cover Image

 

The post WeAreDevelopers Conference App – Open Source & Live Now! appeared first on V-Play Engine.

Qt Creator 4.3 RC1 released

We are happy to announce the release of Qt Creator 4.3 RC1.

Since the Beta release we have kept ourselves busy fixing bugs, so please take this last opportunity to test and give us feedback. Take a look at the Beta release blog post or the more detailed change log for an overview of what has changed in 4.3.

Get Qt Creator 4.3 RC1

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.

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

KDAB trainings at CppCon 2017

Registrations for CppCon 2017 have just opened!

CppCon is the annual conference for the C++ community: five days packed with amazing talks, inspiring keynotes, panel discussions, hallway chats, funny evening events and much more.

CppCon is a project of the Standard C++ Foundation, a not-for-profit organization whose purpose is to support the C++ software developer community and promote the understanding and use of modern, standard C++ on all compilers and platforms.

This year KDAB is proud to be hosting

The post KDAB trainings at CppCon 2017 appeared first on KDAB.

foss-north 2017 follow-up

On the morning of April 26 I arrived at our venue, preparing for around 120 people to fill the rooms at foss-north 2017.

I’m still in the post-event cleaning up phase, so the visitor questionnaire has not yet been sent out, but the feeling is positive. This year we expanded changed venue and moved from one to two tracks. This led to more administration with two room hosts and double video recordings, so that everyone could see everything. The videos are available online now. You can either find a specific talk from the talks and speakers page, or simply enjoy the entire playlist here:

I’d like to extend a big thank you to everyone who made this possible: Jeena and Johnny helping out recording videos and hosting. All our speakers. Our partners Swedsoft, FSFE and BRG. Our sponsors Semcon, Rebel Alliance, Blackduck Software, Capture Innovation and Qamcom. And all the visitors. Without anyone of these pieces, the puzzle would not come together.

I’m already looking forward to seeing you next year again!

new QtSensor IoT plugins!

I've said it before and I will say it again... one thing I am tired of hearing about, is that people think Qt is only for UI applications.
WRONG!
Qt is great for IoT as well! even without a UI. (IoT is today's buzzword for 'embedded', which really isn't embedded, just small) and you cannot have IoT without sensors!

I just submitted a MR to QtSensors to add support for the SenseHAT sensor board for raspberry pi:

https://codereview.qt-project.org/#/c/193456
For raspberry pi, you will need RTIMULib installed on your rpi (and dev package to compile QtSensors). It's in the default repo, so you don't actually need to compile RTIMULib yourself.

Even though this is submitted for dev branch and should be available in Qt Sensors 5.10, this will compile and work for the Qt 5.3 that comes with the raspbian distribution.

As well, if my spare time allows, I will also get my Matrix Creator QtSensor plugin into shape to submit as well.

I also have planned getting the TI SensorTag code I wrote shoved into a QtSensor plugin. What's special about the SensorTag is that it has (buzzword alert) wireless sensors! This is a bit more tricky as it will use and be dependent on Qt's QLowEnergyService but will work nonetheless. This plugin doesn't run on the device, but requires a host machine which has bluetooth.

Qt from git on the Tinkerboard (with Wayland)

The Asus Tinkerboard is a nice little board for Embedded Linux (or Android, for that matter), based on the Rockchip RK3288 SoC including a quad-core ARM Cortex-A17 CPU and a Mali-T760 MP4 (T764) GPU. Besides being quite powerful, it has the advantage of being available locally in many countries, avoiding the need to import the boards from somewhere else. It has its own spin of Debian, TinkerOS, which is what we are going to use here. This is not the only available OS/distro choice, check for example the forums for other options.

We are going to set up the latest qtbase and qtdeclarative from the dev branch, and, to make things more interesting, we are going to ignore X11 and focus on running Qt applications via eglfs with the DRM/KMS backend. This is fairly new for Qt on Mali-based systems: in the past (for example, on the ODROID-XU3) we have been using the fbdev-based EGL implementation. Additionally, Wayland, including Qt-based compositors, is functional as well.

tinkerboard_1

First Things First

qtbase/dev recently received a patch with a simple device spec for the Tinkerboard. Make sure this is part of the checkout of the qtbase tree you are going to build.

As usual, we are going to cross-compile. The steps are pretty similar to the Raspbian guide in the Wiki. I have been using this TinkerOS 1.8 image as the rootfs. To get a suitable ARM (32-bit) cross-compiler for x64, try this Linaro toolchain.

When it comes to the userspace graphics drivers, I have been using the latest “wayland” variant from the Firefly RK3288 section at the Mali driver page. Now, the TinkerOS image does actually come with some version/variant of the binary drivers in it so this step may or may not be necessary. In any case, to upgrade to this latest release, get malit76xr12p004rel0linux1waylandtar.gz and copy the EGL/GLES/GBM/wayland-egl libraries to /usr/lib/arm-linux-gnueabihf. Watch out to have all symlinks adjusted.

As the final preparation step, let’s disable auto-starting X: systemctl set-default multi-user.target.

Sysroot, Configure, Build

From this point on, the steps to create a sysroot on the host machine and to build qtbase against it are almost completely the same as in the earlier Wiki guides for the RPi. Feel free to skip reading this section if it all looks familiar already.

  • Install some development headers and libraries on the target: sudo apt-get build-dep qt4-x11 libqt5gui5 wayland weston.
  • Create a sysroot on the host:
    mkdir -p ~/tinker/sysroot/usr
    rsync -e ssh avz linaro@...:/lib ~/tinker/sysroot
    rsync -e ssh avz linaro@...:/usr/include ~/tinker/sysroot/usr
    rsync -e ssh avz linaro@...:/usr/lib ~/tinker/sysroot/usr
    

    (NB. this is a massive overkill due to copying plenty of unnecessary stuff from /usr/lib, but will do for now)

  • Make all symlinks relative:
    cd ~/tinker
    wget https://raw.githubusercontent.com/riscv/riscv-poky/master/scripts/sysroot-relativelinks.py
    chmod +x sysroot-relativelinks.py
    ./sysroot-relativelinks.py sysroot
    
  • Configure with -device linux-tinkerboard-g++:
    ./configure -release -opengl es2 -nomake examples -nomake tests -opensource -confirm-license -v \
    -device tinkerboard -device-option CROSS_COMPILE=~/tinker/toolchain/bin/arm-linux-gnueabihf- \
    -sysroot ~/tinker/sysroot -prefix /usr/local/qt5 -extprefix ~/tinker/qt5 -hostprefix ~/tinker/qt5-host
    

    Adjust the paths as necessary. Here the destination on the target device will be /usr/local/qt5, the local installation will happen to ~/tinker/qt5 while the host tools (qmake, moc, etc.) go to ~/tinker/qt5-host.

  • Then do make and make install as usual.
  • Then rsync qt5 to /usr/local on the device.

Watch out for the output of configure. The expectation is something like the following, especially when it comes to EGLFS GBM:

EGL .................................... yes
  ...
  OpenGL:
    Desktop OpenGL ....................... no
    OpenGL ES 2.0 ........................ yes
    OpenGL ES 3.0 ........................ yes
  ...
Features used by QPA backends:
  evdev .................................. yes
  libinput ............................... yes
  ...
QPA backends:
  ...
  EGLFS .................................. yes
  EGLFS details:
    ...
    EGLFS GBM ............................ yes
    ...
  LinuxFB ................................ yes
  VNC .................................... yes
  ...

Action

Build and deploy additional Qt modules as necessary. At this point QWindow, QWidget and Qt Quick (QML) applications should all be able to run on the device.

Few notes:

  • Set LD_LIBRARY_PATH, if needed. If the Qt build that comes with the system is still there in /usr/lib/arm-linux-gnueabihf, this is pretty much required.
  • When using a mouse, keyboard or touchscreen, make sure the input devices have sufficient permissions.
  • Enable logging by doing export QT_LOGGING_RULES=qt.qpa.*=true.

As proven by the logs shown on startup, applications will use the eglfs_kms backend which is good since it gives us additional configurability as described in docs. The OpenGL ES implementation seems to provide version 3.2 which is excellent as well.

One thing to note is that the performance may suffer by default due to not running at high enough frequency. So if for instance the qopenglwidget example seems to get stuck at 20 FPS after startup, check this forum thread for examples on how to change this.

Wayland

Yes, QtWayland just works. Here is the minimal-qml compositor example with some clients:

tinkerboard_2

One thing to note is that the default egl_platform.h leads to a build failure in qtwayland. To circumvent this, add a cast to EGLNativeWindowType in the problematic eglCreateWindowSurface call.

That’s all for now, have fun with the Tinkerboard!

The post Qt from git on the Tinkerboard (with Wayland) appeared first on Qt Blog.

QStringView Diaries: Masters Of The Overloads

The last blog post in this series described how to use string-views. This post is about how to design one. In particular, it’s about QStringView‘s constructors. They evolved through a rapid succession of changes. These changes either fixed ambiguities between QString and QStringView overloads, or improved performance. And they all have the same solution: std::enable_if, the Swiss Army Knife for overload control.

This post will take you from where we naïvely started to where we made the impossible possible: overloading a function for arrays and pointers.

continue reading

The post QStringView Diaries: Masters Of The Overloads appeared first on KDAB.

Styling Qt Quick Controls with Photoshop (research)

The Qt Quick Controls 2 undoubtedly have a great look and feel out-of-the box. But if the available styles don’t suit your needs, you can customize the look and feel by defining your desired style in QML.

Styling without coding QML?

However, we at Qt are wondering: what if you want to have your Qt Quick Controls 2 to be styled by a graphic designer? A designer certainly masters tools like Photoshop, Illustrator, SketchApp or similar, and may want to use these tools directly for that styling task without coding QML. Also according to Qt users’ feedback, a repeatable workflow involving a design tool and automatic styling of the application would be very appreciated.

Plan to support image based styling

Qt will support such a workflow with an upcoming version of Qt. The effort can be split in two major tasks:

  1. Adding support for image based styling in Qt Quick Controls 2. That feature will scan through a directory of images and apply them to the controls according to a file naming convention like “control-subitem-state.png”.
    The feature implementation is in progress. One nice extra feature worth mentioning is the support of Nine-patch images which are certainly known by Android developers and which are supported by a few tools out there.

  2. Creating “template” style documents first for Photoshop (and then for others) which have the required structure (e.g. special layer names) to export the image elements with the right names. Style designers can take these templates as a starting point. One promising option for exporting is the built-in Asset Exporter of Photoshop, perhaps with custom extensions to it. We are however also considering other options.

Research implementation

In order to try out how such envisioned workflow feels like and in order to get early feedback by Qt users, we implemented the following example project. An included Photoshop document can be used to define the style of a few Controls. The style images get exported by the Asset exporter and land in the resources of the example application. In order to be able to develop this example under Qt 5.8 and 5.9 which do not yet contain image based styling and Nine-patch images, the example includes its custom image style and assumes a fixed border size for the border images.
This means you can clone the example right now from the git repo or download the zipped sources.

We demonstrated the example at the Embedded World 2017 and got quite positive feedback from interested users. A film crew was also there and filmed me performing my demonstration.

The research implementation in pictures

The style in Photoshop
A designer can work with the provided style template and tweak it in order to meet the desired look.

The style in Qt Quick Designer
The Qt Quick Designer tool in the Qt Creator IDE provides a preview of the style while the form is being edited.

targetdevice
The launched application (in this example on an embedded device) is using the style.

Items left to be researched…

  1. Some styling data like font faces, text colors, etc. should also be possible to be defined in the design tool and be exported as metadata in conjunction with the image files. In the case of Photoshop, there are a few options to achieve we have in mind. We still need to evaluate these options.

  2. How to generate Nine-patch images. Also here, we see a few options worth to be tried out.

What do you think of the plan? Please leave a comment below to let us know 🙂 Thank you for reading.

The post Styling Qt Quick Controls with Photoshop (research) appeared first on Qt Blog.

Qt World Summit 2017 Call for Presentations

QtWS17 CfPBuild for Tomorrow – Deliver Today

The Qt World Summit 2017 in Berlin, Germany this October is where the Qt community comes together from all around the world. This year, the theme of the event is “Build for Tomorrow – Deliver Today”.

The Call for Presentations is Now Open!

However please read through this guide before running off to submit your presentation.

Key Dates

  • The call is open now!
  • The call will close on 30.5.2017.
  • The authors of accepted topics will be informed in early June.
  • The list of accepted topics will be publicly available in mid June.
  • Full presentations / slide submissions must be made by 15.9.2017

Themes and Focus areas

As the theme for Qt World Summit 2017 suggests, the focus of the event will be on the future of software. Recently, Qt received a significant contribution from NVIDIA, and the Qt3D module has seen a lot of improvement. In line with this, we are emphasizing 3D graphics and user interfaces as one main area in our call for presentations.

In the past year Qt has seen strong growth in the automotive segment and embedded devices overall. We are also looking for presentations that dive into all the phases of an embedded devices’ life-cycle, and we would like to hear your views on how Qt is a part of the innovation happening across a variety of industries.

Qt is a cross platform framework, we are also excited about what you have to say about application development, a strong area for Qt. The tooling and SDK in Qt has always been an important part of our story, so that is included in the call.

Software ecosystems are still an important trend in development. Qt can be used to enable your ecosystem or as part of your SDK.

In addition, other areas of interest include automation systems, medical systems and multi-screen applications.

To summarize the above, we are calling for presentations on:

  • Future of software with Qt
  • 3D User interfaces and Graphics, including AR and VR
  • Automotive solutions
  • Application development and Qt enabling application ecosystems
  • Tools, methods and processes for the embedded device life-cycle
  • Automation systems

Did we miss something? The latest advancements and improvements in Qt are also welcome as always. You can also submit presentations on any topic related to Qt.

Business track

This year we will be hosting a business track, with presentations that demonstrate the business aspects of Qt in software development.

  • Cases and examples of Qt in use
  • Time to market
  • Software life-cycle
  • Development team setup and composition
  • Ecosystems from the business aspect

Program committee and selection criteria

The Program committee includes members from The Qt Company and Qt Partners. The committee will review all submissions and jointly select presentations for the Qt World Summit.

There are many ways to write an abstract, but here are some tips for an easy to read, easy to understand abstract that is sure to win a slot on the Qt World Summit agenda:

  • Show a clear intent and purpose
  • Make clear what the value to the intended audience is
  • Keep in mind the summit’s themes and focus
  • Offer something unique and unexpected, yet relevant is to the event’s focus areas

The committee will make their decision based on the outlined themes of the event. The committee will also make sure that the selected presentations support a varied and overall diverse spectrum of interesting presentations – both in terms of technical level and focus areas to provide value for event participants.

Session Length

You may propose either a 25 or 50 minute session.

Audience

Topics should be of interest to all attendees. The Qt World Summit attracts people from all corners of the Qt community. This year, we can expect technology directors, developers and engineers, as well as business decision makers, product and project managers will be attending the event.

Speaker Benefits

As a speaker, you will receive a Free Access -pass to the Qt World Summit. This is a great opportunity to spread your mindshare and have a community of industry leaders and important software developers hear your message. We will be recording the presentations; speaking at the Qt World Summit will give you an audience that goes beyond the crowd attending your presentation in Berlin. The material from your talk will also be made available to all of the attendees after the event.

We will share your contact and professional details on the Qt World Summit web pages, giving you a large platform to network with anyone interested in your expertise and/or offering.

Submit Your Talk Today!

https://www.surveymonkey.com/r/QtWS17

For more information of if you have any questions, please contact qtws@qt.io.

The post Qt World Summit 2017 Call for Presentations appeared first on Qt Blog.

Performance regression testing of Qt Quick

by Eskil Abrahamsen Blomfeldt (Qt Blog)

We recently added a new toy to The Qt Project, and I wanted to give an overview on what it is and how it can be used.

Grafana showing results of running benchmarks

Grafana showing results of running benchmarks

qmlbench testing

The new toy is automated performance testing, and the background (long story short) is that in order to avoid regressions in performance, automated testing is required. This is no different from avoiding regressions in functionality, and it may sound obvious. But while we have many benchmarks in Qt, we have unfortunately only been running them manually, and, as a result, regressions have snuck into the released product from time to time.

This year, The Qt Company decided to invest into fixing the problem, and I was given the task to set up performance testing of Qt Quick and the scene graph. The plan is to add benchmarks for all areas of Qt to the same system, but in order to get the infrastructure in place first, we decided to use Qt Quick as the pilot project.

I decided to go with the tool that Robin Burchell and Gunnar Sletta wrote for this, recently contributed to The Qt Project: qmlbench.

The tool is designed to measure the performance of Qt Quick primitives and functionality, and it has a suite of QML files that are intended for automated testing.

To be able to see how performance evolves over time and to detect even smaller regressions, we decided to go with a graph approach that we manually monitor for changes. While we are still working to reduce it as much as possible, there will always be a bit of noise and fluctuation in the benchmarks, due to the hardware and operating systems themselves not being 100% predictable.

The resulting graphs can be seen in testresults.qt.io.

And the news are good: Qt 5.9 is a great improvement on Qt 5.6 (I expect around 15% on average when it is released) and the tool has already detected performance regressions which we have subsequently fixed. Lets go into some more detail.

How to use the UI

When you first look at the page linked above, there will be a lot of information at once, but luckily it is easy to change the view to only show what you are interested in.

Say for instance that I only want to see the results of a single benchmark, e.g. “changing_over_isolated_with_clip_rotated”. I can do that by using the “benchmark” selector in the top left corner.

select benchmark

In the same row, you can also select which machine you want to see results for. The currently available ones are “eskil_linux_foucault”, which is a Ubuntu desktop machine with an NVIDIA Quadro graphics card, and “eskil_linux_tx1” which is an arm-based NVIDIA Jetson TX1, also running Ubuntu.

In the view of the graphs themselves, you can turn on and off data sources by clicking on the labels (hold shift to select multiple). By default, you will see the benchmark results and the coefficient of variation for each branch. On desktop, it is currently running for 5.6, 5.8, 5.9, dev and v5.8.0. The last one is there as a control, to be able to exclude changes to qmlbench itself as well as OS and hardware related issues. On the TX1, we are only running for 5.6 and 5.9 at the moment, given the time it takes for a single test run on that hardware.

selectsources

In the screenshot above, I have disabled everything except the 5.6 and 5.9 benchmark results.

Finally: In the top right corner, you can select the time resolution of the current view. You can also zoom in on an area of a graph by clicking and dragging over the area. All the different tables and graphs will adapt automatically to the currently selected time interval.

This was just a very quick overview of Grafana. Consult the full documentation for more information.

How to use the graphs

The main way to use the graphs is to monitor them and look for changes that persist over time. Note that higher is better for these benchmarks, as they are counting how many frames can be drawn during a predefined time period (20 seconds) for a predefined test size. There is also a table that shows the median in the current interval, for an easy way to compare branches and detect regressions/improvements.

Also note that the rendering caps at 60 fps, so the maximum result we can get is 1200 frames per 20 seconds. So graphs will cap at this level and we will not get much useful information from them before we increase the complexity of the scenes they are rendering.

In addition to the performance data, you also have access to the “coefficient of variation” for each test run. The scale of the CoV is on the right side of the graph view. When running the benchmark, we will do five runs in sequence and report the average of this to the database. This is to avoid always running on cold data and it decreases the fluctuations in the graphs. The CoV is based on the standard deviation of these datasets of five results. It can give you an idea of the stability of the test results, though there are some very stable test that still report a high CoV, such as the “sum10k.qml” test. For some reason which we have yet to figure out, the first run will always be around 230 frames on that particular machine and then all the subsequent runs will be 440. So the average is stable, but the CoV is through the roof. Since this is not reproducible anywhere else, Robin suggested the machine is haunted, which is so far our best guess.

If you look at each of the graphs, you will see that for most of them the “5.9” line is above the “5.6” line, which is good, since it means performance is improving. On average, I expect that Qt 5.9 will give approximately 15% better performance than Qt 5.6. If you look specifically at any of the layout tests, you will see that you can get around 50% performance improvement on your Qt Quick layouts just by upgrading to Qt 5.9 from Qt 5.6.

Graphs showing 53% performance improvement on creation of column layouts.

Graphs showing 53% performance improvement on creation of column layouts in Qt 5.9 compared to Qt 5.6.

The main objective of having this tool, however, is to detect and fix regressions, and there was one test that worried us: the “changing_over_isolated_with_clip_rotated” test case.

This test verifies that we can isolate a subtree in the scene graph by using a clip node even if the clip is rotated, so that it is put into its own batch in the renderer. Thus changing it does not affect the other parts of the scene graph. If you look at the graph in Grafana, you will see that until very recently, we had a significant regression in that area. On April 25th, the regression was fixed, so it will never be released to users.

changing_over_isolated_with_clip_rotated

Now, if I saw this graph and wanted to find out what happened, there is another helpful tool which I haven’t yet talked about. You can enable it by checking the “annotations” checkbox on the top of the page. This will show, as events in the graphs, the SHA1s for the different modules we are testing at any given time. Note that this is still a bit of a work in progress: To avoid cluttering the graphs too much, we are only reporting the SHA1s for the eskil_linux_foucault machine. If there are several events at the same time, you will also have to zoom in a bit to be able to separate them. So the UI isn’t perfect, but it works when you need to dig for information.

If I do zoom in on the first result where performance has been improved, I will see that one of the updates was to Qt Declarative. I can hover over the event to see the SHA1 of the update.

annotation

By going to the git repository, I can easily find the diff between the two commits listed. If I do, I will see that one of them is Fix a performance regression noted by qmlbench by Robin Burchell.

So the system is working. If regressions pop up while the tool is running, we will be able to find the offending commit just as easily.

The future

What’s next you ask? We will of course continue to improve the qmlbench test set as well as the tool itself. We may also add more platforms to the farm when the need arises.

In addition, there are several other people in The Qt Company who are working on getting benchmarks for other parts of Qt into the same system. In the time to come, we will get unit benchmarks for different parts of Qt, startup time measurements, Qt Creator performance testing, QML engine testing, etc. into the same system. Look for updates here and on the main benchmark home page.

The post Performance regression testing of Qt Quick appeared first on Qt Blog.

Cutelyst 1.6.0 released, to infinity and beyond!

Once 1.5.0 was release I thought the next release would be a small one, it started with a bunch of bug fixes, Simon Wilper made a contribution to Utils::Sql, basically when things get out to production you find bugs, so there were tons of fixes to WSGI module.

Then TechEmpower benchmarks first preview for round 14 came out, Cutelyst performance was great, so I was planning to release 1.6.0 as it was but second preview fixed a bug that Cutelyst results were scaled up, so our performance was worse than on round 13, and that didn't make sense since now it had jemalloc and a few other improvements.

Actually the results on the 40+HT core server were close to the one I did locally with a single thread.

Looking at the machine state it was clear that only a few (9) workers were running at the same time, I then decided to create an experimental connection balancer for threads. Basically the main thread accepts incoming connections and evenly pass them to each thread, this of course puts a new bottleneck on the main thread. Once the code was ready which end up improving other parts of WSGI I became aware of SO_REUSEPORT.

The socket option reuse port is available on Linux >3.9, and different from BSD it implements a simple load balancer. This obsoleted my thread balancer but it still useful on !Linux. This option is also nicer since it works for process as well.

With 80 cores there's still the change that the OS scheduler put most of your threads on the same cores, and maybe even move them when under load. So an option for setting a CPU affinity was also added, this allows for each work be pinned to one or more cores evenly. It uses the same logic as uwsgi.

Now that WSGI module supported all these features preview 3 of benchmarks came out and the results where still terrible... further investigation revealed that a variable supposed to be set with CPU core count was set to 8 instead of 80. I'm sure all this work did improve performance for servers with a lots of cores so in the end the wrong interpretation was good after all :)

Preview 4 came out and we are back to the top, I'll do another post once it's final.

Code name "to infinity and beyond" came to head due scalability options it got :D

Last but not least I did my best to get rid of doxygen missing documentation warnings.

Have fun https://github.com/cutelyst/cutelyst/archive/v1.6.0.tar.gz

Efficient barcode scanning with QZXing

QZXing is a very useful library: It provides an easy to use Qt integration API around the barcode scanning library ZXing (zebras crossing).

Because it is so easy to setup QZXing in a Qt application, we and most of our customers end up using it when they need to scan images for barcodes. There is, or rather was, a big problem though: When you want to analyze a live camera video stream, e.g. from a phone camera, the latency can easily be so large that it affects usability. The user needs to hold the camera very still on the barcode and often wait for multiple seconds until the barcode is detected.

Towards the end of last year, I decided to do something about this. At KDAB I have the freedom to spent 10% of my time on education projects. Optimizing and improving a commonly used library like QZXing also falls into this category.

The following outlines what I learned about using QZXing. I also talk a bit about the many optimizations I upstreamed to the project, which drastically improve its performance. Combined, these steps will lead to a much smoother user experience when scanning barcodes. If you have seen our Kurth KE3600 xDSL Multitester demo at Embedded World Nuremberg, you already got in direct contact with some of the fruits of this work.

continue reading

The post Efficient barcode scanning with QZXing appeared first on KDAB.

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.