Embed Qt

It looks like “git am” operates differently from eg. git rebase, since if a patch fails to apply git am bails out without trying to insert the familiar “<<<<<<<” and “>>>>>>>” indicators.

Using threads in C and C++ code is never easy: there are many ways to break code and inject difficult to find bugs. Threading bugs also have a nickname, “Heisenbugs”, bugs that manifest themselves only when you are NOT actively looking for them.

If you really have to use threads in your application, here are some pitfalls that can make your life harder.

1. Lock acquisition failures

Have a look at this code:

if ( !mutexA->tryLock(timeout) || !mutexB->tryLock(timeout) )

       return;

Everything seems legit, but do you see the bug?

Not easy, huh?

The point is that mutexB acquisition may fail, but the code is not releasing mutexA correctly. Always try to use QMutexLocker & friends classes, where the destructor takes care of releasing the lock.

In addition, make sure you lock and unlock multiple resources in the proper order to avoid deadlocks. If you lock resources A, B, C in order, then the correct unlocking order is C, B, A.

2. QtConcurrent::run()

QtConcurrent makes it very easy to run a function in another thread...sometimes too easy!

void SomeClass::doStuff() {

    QtConcurrent::run(this, &SomeClass::doInternalStuff);

}

This code is running a method of SomeClass in another thread, so if you access some class members you must use locks. If you coded the method before using QtConcurrent::run() you have probably introduced an Heisenbug.

3. Taking results from QFuture

QtConcurrent::run() returns a QFuture, the result of an async computation. Calling result() on a QFuture is a blocking operation, therefore code like the following is redundant:

QFuture<bool> error = QtConcurrent::run(...);

return error.result();

Don’t use this pattern when it’s ok to have a blocking call; it may hide subtle bugs when you later add code. For example:

QFuture<bool> error = QtConcurrent::run(...);

if(error.isFinished())

    emit resultReady();

return error.result();

I’ve searched the Internet for simple howtos on how to write a systemd service file from scratch but I haven’t found any, so here it is: a howto on writing minimal service files for embedded systems processes.

You may want to familiarize with some basic concepts before going on.

A service file is very similar to an INI file in its structure. A basic file has 3 sections: Unit, Service and Install

[Unit]

Basic information about the service. The most important entries are:

Description: a simple description of your process;

Wants: list all services that are needed for this process. If your program uses socket or dbus activation the dependencies are automatic and you don’t need this entry;

After: wait for the listed services to go up before starting your process. Again, this is only needed in case you are not using socket or dbus activation.

[Service]

This section actually specifies the executable you want to launch and the running behaviour. The most important entries are:

ExecStart: the absolute path of the executable to start;

Environment: use this to set relevant environment variables for your process. Example

Environment=EGLFS_HIDE_CURSOR=1 “POINTERCAL_FILE=/path/with spaces/pointercal”

Note that in case of spaces the double quotes enclose also the variable name.

Type: it’s used by systemd to guess which process is the “main” process. Particularly useful when daemons fork a couple of times; not really useful if you just have a single application that you want to launch, set it to simple;

Restart: configure how/when your service should be restarted. For embedded systems always is a reasonable choice;

SuccessExitStatus: a list of signals or numbers (other than 0) that indicate a successful exit status.

By the way, multiple forking is the standard way to daemonize from shell, read the docs for more information.

[Install]

This section is useful if you want to enable or disable your service. In systemd parlance, a service is enabled if it automatically starts at boot; you usually want this for embedded systems. Mainly this boils down to:

[Install]

WantedBy=multi-user.target

Complete example

Here is a complete example of a standalone application that we want to start at boot:

[Unit] Description=Description for myprogram Wants=rpcbind.service After=rpcbind.service

[Service] Environment="MY_ENV_VAR=/some/path/to/file with space.ini" ExecStart=/usr/local/myprogram Type=simple

[Install] WantedBy=multi-user.target

Documentation

Official systemd documentation

The Qt TestCase documentation gives a very simple example of how a QML unit test is structured.

TestCase { name: "MathTests" function test_math() { ... } function test_fail() { ... } }

However, if you naively extend the test case you won't get mouse input events.

TestCase { name: "MathTests" MyItem { id: myItem } function test_item() { mouseClick(myItem, 10, 10) // this will not work } }

This is because...TestCase is an invisible item, so mouse events are not delivered!

It's enough to wrap everything with an external Item, like this:

Item { MyItem { id: myItem } TestCase { name: "MathTests" function test_item() { mouseClick(myItem, 10, 10) // now works correctly! } }

Profiling a remote QtQuick 2.0 application is really easy, you just need to follow these steps:

Define the macro QT_QML_DEBUG before including <QtQuick>: your best option is to use DEFINES += QT_QML_DEBUG when launching qmake

Launch your remote application with the command line option -qmljsdebugger=port:3768,block

Back in Qt Quick 1.x, it was possible to do custom actions in response to specific URL schemas loaded in a QML WebView; however that was inconvenient to say the least, since you had to use a custom QNetworkAccessManager, check the URL for each request and then do the desired action.

Fast forward to QtWebKit 3.0, the custom QNAM is gone, but there's a simpler API to achieve the same results: the urlSchemes property in the experimental module.

New awesome performance improvements in Qt 5.2.

A few notes about the Tegra 3 as an embedded platform:

In Qt 5.1 the rendering time is still quite high, which confirms with numbers my previous observations on other embedded platforms. Graphically the ExtremeTable example is a still object with a semi-transparent moving object above it, which is a fairly common use case.

CPU usage dropped significantly when the scene has lots of moving objects. Again this is a nice improvement, especially on embedded where every cycle counts.

PNG files by default are treated as transparent, even if there are no transparent pixels. The only way to have full opaque PNG images is to use a custom QQuickImageProvider, which is a bit boring to use.

A few days ago I was doing a port of a QtQuick 1 embedded software to QtQuick 2. In this software there's a browser which has some fairly standard functionality such as: SSL certificates updates, security exceptions for invalid SSL certificates, custom behaviour for unsupported MIME types.

All of this was fairly straightforward in QtQuick 1 because you could create a custom network access manager for your QML engine (through a custom QNetworkAccessManagerFactory) and WebKit would simply use that. However, this is no more the case for WebKit2.

Let's quickly review the architecture of WebKit2:

UIProcess: the process responsible of communicating with the user

WebProcess: the rendering process

The two communicate via a channel with a set of standard messages.

When you want to port WebKit to your platform, you need to implement two things: the public API, which is what your users will see, and the process API, which is needed by the WebProcess (for example, network communication).

This is a fairly standard pattern when creating large and modular software. So, how is Qt connected to WebKit?

At the public API level it exposes the QML WebView element and other C++ classes (QWebPage, QWebFrame...)

At the WebProcess API level, it uses standard Qt classes to implement the low level WebKit API; in particular, network requests are handled by an instance of QNetworkAccessManager.

Now we see that the main process' NetworkAccessManager is not used to download web pages, since such communication is done in another process.

So, how to implement SSL root CA certificates update? Just update them at the system level, under /usr/lib/ssl/certs/.