Injeqt 0.9.0 released

First official (beta!) version of Injeqt dependency injection library for Qt was released today. I can be downloaded from GitHub releases page.

For last 3 weeks I was working on Kadu and switching some parts of it to use Injeqt for its objects and services wiring. As it turns out, it all works very well already. There is no need to postpone Injeqt release until it gains additional features (and I have big plans for it).

0.9.x series will continue until Kadu 2.0 release with only bugfixes. I don't expect a lot of them (Injeqt has very nice unit tests coverage), but better safe than sorry. Exported API is very minimal and should not be changed (only extended) in a long time.

If you wish to try it - please do it now. I would be happy to see more use cases and real world applications before committing 100% to 1.0 release.

Enjoy!

Qt Weekly #20: Completing the offering: QOpenGLWindow and QRasterWindow


Together with the introduction of QOpenGLWidget, Qt 5.4 adds two more classes: QOpenGLWindow and QRasterWindow. Let us now look at the list of native window classes and OpenGL container widgets. The list may look long and confusing at first glance, but it is all quite logical so everything will fall into place quickly:

  • QWindow: Represents a native window in the windowing system. The fundamental window class in Qt 5. Every top-level window, be it widget or Quick based, will have a QWindow under the hood. Can also be used directly, without widgets or Quick, both for OpenGL and software rendered graphics. Has no dependencies to the traditional QWidget stack.
  • QRasterWindow: Convenience wrapper over QWindow for software rendered graphics.
  • QOpenGLWindow: Convenience wrapper over QWindow for OpenGL graphics. Optionally backed by a framebuffer object, but the default behavior (and thus performance) is equivalent to QWindow.
  • QOpenGLWidget: The modern replacement for Qt 4’s QGLWidget. A widget for showing OpenGL rendered content. Can be used like any other QWidget. Backed by a framebuffer object.
  • QQuickWindow: A QWindow subclass for displaying a Qt Quick 2 (QML) scene.
  • QQuickView: Convenience wrapper for QQuickWindow for easy setup of scenes loaded from QML files.
  • QQuickWidget: The equivalent of QQuickView in the QWidget world. Like QOpenGLWidget, it allows embedding a Qt Quick 2 scene into a traditional widget-based user interface. Backed by a framebuffer object.

For completeness sake, it is worth noting two additional APIs:

  • QQuickRenderControl: Allows rendering Qt Quick 2 scenes into framebuffer objects, instead of targeting an on-screen QQuickWindow.
  • QWidget::createWindowContainer(): In Qt 5.1 & 5.2 the only way to embed Qt Quick 2 content (or in fact any QWindow) into a widget-based UI was via this function. With the introduction of QQuickWidget and QOpenGLWidget this approach should be avoided as much as possible. Its usage should be restricted to cases where it is absolutely neccessary to have a real native window embedded into the widget-based interface and the framebuffer object-based, more robust alternatives are not acceptable, or where it is known in advance that the user interface layout is such that the embedded window will not cause issues (for example because the embedded window does not care about input, is not part of complex layouts that often get resized, etc.).

We will now take a look at no. 2 & 3, the QWindow convenience wrappers.

Ever since the introduction of the QPA architecture and QWindow, that is, since Qt 5.0, it has been possible to create windows based on QWindow that perform custom OpenGL drawing. Such windows do not use any QWidget-derived widgets, instead they render everything on their own. A game or a graphics intensive application with its own custom user interface is a good example.

This is the most lightweight and efficient way to perform native OpenGL rendering with Qt 5. It is free from the underlying complexities of the traditional widget stack and can operate with nothing but the QtCore and QtGui modules present. On space-constrained embedded devices this can be a big benefit (no need to deploy QtWidgets or any additional modules).

Power and efficiency comes at a cost: A raw QWindow does not hide contexts, surfaces and related settings, and it does not provide any standard mechanism for triggering updates or opening a QPainter (backed by the OpenGL 2.0 paint engine) targeting the window’s associated native window surface.

For example, a simple QWindow subclass that performs continous drawing (synchronized to the display’s vertical refresh by the blocking swapBuffers call) both via QPainter and directly via OpenGL could look like the following:

class MyWindow : public QWindow
{
public:
    MyWindow() : m_paintDevice(0) {
        setSurfaceType(QSurface::OpenGLSurface);

        QSurfaceFormat format;
        format.setDepthBufferSize(24);
        format.setStencilBufferSize(8);
        setFormat(format);

        m_context.setFormat(format);
        m_context.create();
    }

    ~MyWindow() { delete m_paintDevice; }

    void exposeEvent(QExposeEvent *) {
        if (isExposed())
            render();
    }

    void resizeEvent(QResizeEvent *) {
        ...
    }

    void render() {
        m_context.makeCurrent(this);

        if (!m_paintDevice)
            m_paintDevice = new QOpenGLPaintDevice;
        if (m_paintDevice->size() != size())
            m_paintDevice->setSize(size());

        QOpenGLFunctions *f = m_context.functions();
        f->glClear(GL_COLOR_BIT | GL_DEPTH_BUFFER_BIT);
        // issue some native OpenGL commands

        QPainter p(m_paintDevice);
        // draw using QPainter
        p.end();

        m_context.swapBuffers(this);

        // animate continuously: schedule an update
        QCoreApplication::postEvent(new QEvent(QEvent::UpdateRequest), this);
    }

    bool event(QEvent *e) {
        if (e->type() == QEvent::UpdateRequest) {
            render();
            return true;
        }
        return QWindow::event(e);
    }

private:
    QOpenGLContext m_context;
    QOpenGLPaintDevice *m_paintDevice;
};

Now compare the above code with the QOpenGLWindow-based equivalent:

class MyWindow : public QOpenGLWindow
{
public:
    MyWindow() {
        QSurfaceFormat format;
        format.setDepthBufferSize(24);
        format.setStencilBufferSize(8);
        setFormat(format);
    }

    void resizeGL(int w, int h) {
        ...
    }

    void paintGL() {
        QOpenGLFunctions *f = context()->functions();
        f->glClear(GL_COLOR_BIT | GL_DEPTH_BUFFER_BIT);
        // issue some native OpenGL commands

        QPainter p(this);
        // draw using QPainter

        // animate continuously: schedule an update
        update();
    }
};

That is a bit shorter, isn’t it. The API familiar from QOpenGLWidget (initializeGL/resizeGL/paintGL) is there, together with the update() function and the ability to easily open a painter on the window. While QOpenGLWindow, when used this way, does not remove or add anything compared to raw QWindow-based code, it makes it easier to get started, while leading to shorter, cleaner application code.

QRasterWindow follows the same concept. While everything it does can be achieved with QWindow and QBackingStore, like in the raster window example, it is definitely more convenient. With QRasterWindow, the example in question can be reduced to something like the following:

class RasterWindow : public QRasterWindow
{
    void paintEvent(QPaintEvent *) {
        QPainter painter(this);
        painter.fillRect(0, 0, width(), height(), Qt::white);
        painter->drawText(QRectF(0, 0, width(), height()), Qt::AlignCenter, QStringLiteral("QRasterWindow"));
    }
};

Painters opened on a QOpenGLWindow are always backed by the OpenGL paint engine, whereas painters opened on a QRasterWindow are always using the raster paint engine, regardless of having OpenGL support enabled or available at all. This means that QRasterWindow, just like the traditional widgets, is available also in -no-opengl builds or in environments where OpenGL support is missing.

Now, what about incremental rendering? In the QRasterWindow example above there is strictly speaking no need to clear the entire drawing area on each paint. Had the application wished so, it could have continued drawing over the existing, preserved backing store content in each invocation of paintEvent(), as long as the window did not get resized. With QGLWidget, QWindow or the QOpenGLWindow example shown above this is not possible, unless preserved swap is enabled via the underlying windowing system interface, since on each paintGL() call the color buffer contents is effectively undefined. QOpenGLWidget does not have this problem since it is backed by a framebuffer object instead of targeting the window surface directly. The same approach can be applied to QOpenGLWindow too. Hence the introduction of the different update behaviors that can be set on a QOpenGLWindow.

Take the following QWindow-based code:

class MyWindow : public QWindow
{
public:
    MyWindow() : m_paintDevice(0), m_fbo(0), m_iter(0) {
        ... // like in the first snippet above
    }

    ...

    void render() {
        m_context.makeCurrent(this);

        if (!m_fbo || m_fbo->size() != size()) {
            delete m_fbo;
            m_fbo = new QOpenGLFramebufferObject(size(), QOpenGLFramebufferObject::CombinedDepthStencilAttachment);
            m_iter = 0;
        }

        if (!m_paintDevice)
            m_paintDevice = new QOpenGLPaintDevice;
        if (m_paintDevice->size() != size())
            m_paintDevice->setSize(size());

        m_fbo->bind();
        QPainter p(m_paintDevice);

        // Draw incrementally using QPainter.
        if (!m_iter)
            p.fillRect(0, 0, width(), height(), Qt::white);

        p.drawText(QPointF(10, m_iter * 40), QString(QStringLiteral("Hello from repaint no. %1")).arg(m_iter));

        ++m_iter;

        p.end();
        m_fbo->release();

        // Now either blit the framebuffer onto the default one or draw a textured quad.
        ...

        m_context.swapBuffers(this);

        // animate continously: schedule an update
        QCoreApplication::postEvent(new QEvent(QEvent::UpdateRequest), this);
    }

private:
    QOpenGLContext m_context;
    QOpenGLPaintDevice *m_paintDevice;
    QOpenGLFramebufferObject *m_fbo;
    int m_iter;
};

For brevity the code for getting the framebuffer’s content onto the window surface is omitted. With QOpenGLWindow’s PartialUpdateBlit or PartialUpdateBlend the same can be achieved in a much more concise way. Note the parameter passed to the base class constructor.

class MyWindow : public QOpenGLWindow
{
public:
    Window() : QOpenGLWindow(PartialUpdateBlit), m_iter(0) {
        QSurfaceFormat format;
        format.setDepthBufferSize(24);
        format.setStencilBufferSize(8);
        setFormat(format);
    }

    void resizeGL(int, int) {
        m_iter = 0;
    }

    void paintGL() {
        QPainter p(this);

        // Draw incrementally using QPainter.
        if (!m_iter)
            p.fillRect(0, 0, width(), height(), Qt::white);

        p.drawText(QPointF(10, m_iter * 40), QString(QStringLiteral("Hello from repaint no. %1")).arg(m_iter));

        ++m_iter;

        update();
    }

private:
    int m_iter;
};

That’s it, and there is no code omitted in this case. Internally the two are approximately equivalent. With the QOpenGLWindow-based approach managing the framebuffer object is no longer the application’s responsibility, it is taken care by Qt. Simple and easy.

Native UI in Qt on Android (without QtQuick.Controls)

TL;DR - Yes, you can do a fast, no-compromise native UI without QtQuick on Android, and you'll use a lot less resources than a full QtQuick app, at the cost of somewhat messy code.

Nowadays Qt for Android comes with a nice QtQuick-compatible set of native-looking Android controls in the form of QtQuick.Controls. This blog post is not about them :) Let's go a bit off the beaten path - can we create a Qt application with a graphical, performant, native UI without using QtQuick (or QWidgets)? What are the advantages and disadvantages to such an approach?

In a blog post Artem Marchenko lists a couple of approaches how a Qt based native-looking UI would be possible, but these all include QML in one form another, which is not quite what we're after in this particular case. Another interesting project is Ben Lau's QAndroidRunner which combines native UIs and QML. Here, however, we'll focus how far can you get without ever touching QML or QtQuick.

The key to using Android classes and resources is the QAndroidExtras module (it's an add-on module that has been around since Qt 5.2). The class I'm heavily relying on is QAndroidJNIObject which allows Java class/object instantiation and manipulation. Thus, the two includes we'll use to enable creating native objects are

#include <QtAndroidExtras/QAndroidJniObject>
#include <QtAndroidExtras/QtAndroid>

When it comes to Android UIs, the first stop is the Activity - on Android activities are how we interact with the user. This is effectively a window on which we put all our widgets and UI elements. Luckily, starting with Qt 5.3, we have a simple way of retrieving an activity with the QtAndroid::androidActivity function.

QAndroidJniObject activity = QtAndroid::androidActivity();

Let's get to the meat of the matter - we'll need to create native layout and widget objects and set their parameters from Qt. Here's how that looks like

QAndroidJniObject layout("android/widget/RelativeLayout", 
"(Landroid/content/Context;)V",
activity.object());

The first parameter is the Java class name, the second the Java method signature (see here for a few more examples, "javap -s" is your friend), and the third parameter is the actual object used as the parameter (as activity is a QAndroidJniObject, we need to use the object() method). With the call above we create a Layout and assign it to the activity.

We can also call methods of our objects:

button.callMethod<void>("setTextColor", "(I)V", -1); // Color.WHITE

Putting all these together, we can create a basic, but full-fledged Android application:



...resulting in...


This "Hello world" code is clearly quite a bit more complicated than it's QML counterpart:



The complexity downside is quite obvious - it's hard to beat QML's brevity and clarity. Another, perhaps not immediately visible downside is that this particular style of C++ code is more error-prone - there is no type safety as the objects are generated dynamically, so on errors, it's easy to end up with NULL objects and segfaults.

Why would anyone use it, then? Let's take a look at resource consumption:

The APK size for the non-QML Android version of Hello World is 5,663,420 bytes, while the APK with the Controls included is 10,406,706. The difference could be even bigger, though, as the default android mkspec includes a few extra Qt modules. It should be possible to get the minimum APK size down to around 3MB. If you are using Ministro, this might not be as big of an issue, but for self-contained applications, or embedded, this can shave a few precious megabytes off of the application.

It's not just flash storage and network bandwidth we can save though - there is a memory-usage difference as well. While adb dumpsys meminfo is not a perfect way to measure memory usage, it is indicative:

40761 kB: org.qtproject.example.QtJavaHelloWorld
77531 kB: org.qtproject.example.QmlHelloWorld

While a ~35MB of minimum framework tax might not sound like much in the era of devices with several gigabytes of RAM, using a complex QML structure can inflate the difference further. On embedded and legacy devices every megabyte counts, so even this 35MB difference can help (plenty of low-end Android devices with 256-512MB of RAM).

There are other benefits to not using QtQuick controls - controls are a "lowest common denominator" approach designed to easy cross-platform development. It does not contain all UI widgets and elements, nor functionality offered by Android APIs. By using the approach as demonstrated, there is no compromise - the full UI arsenal is at our disposal, at the exact same performance as for regular Java apps.

Finally, the QtQuick controls version depends on the Qt version shipped with the application. In the non-Controls version we always get the native controls, with native styling and behavior, even if the platform release is newer than what our QtQuick.Controls version supports.

To summarize, the advantages to a Controls-less approach are:
  • Native UI performance
  • Smaller APK size (currently at least ~5MB less, potentially ~7MB)
  • Smaller memory footprint (35MB for Hello world, more as app complexity increases)
  • Full UI functionality available, regardless of Qt version
  • Styling always latest platform-native
Disadvantages

  • Not cross-platform
  • Significantly increased code complexity, especially with more complex UIs
  • Harder to debug due to dynamic nature and lack of tooling support

It's actually possible to mitigate some of the disadvantages, so stay tuned for further posts on this topic!

C++14 for Qt programmers

C++14 is the name of the version of the standard to be released this year. While C++11 has brought many more feature that took time to be implemented by the compilers, C++14 is a much lighter change that is already implemented by compilers such as clang or gcc.

Qt 5 already was adapted in many ways so you can make use of the new features of C++11. You can read about that in my previous article. C++11 in Qt5 . This article mention some of the changes in C++14 and the impact on Qt users.

Generic lambda

C++11 introduced lambda function, and Qt5 allow you to connect signals to them with the new connect syntax. C++14 simplify the use of lambda function as the arguments can be automatically deduced. You can use auto as parameter type instead of explicitly writing the type.

 connect(sender, &Sender::valueChanged, [=](const auto &newValue) {
        receiver->updateValue("senderValue", newValue);
    });

Internally, lambda function is just a functor object with an operator(). With generic lamdba, that operator is now a templated function. I had to make a change which was included in Qt 5.1 already to support such functors.

C++14 also adds the possibility to have expressions in the capture.

 connect(sender, &Sender::valueChanged, [reciever=getReciever()](const auto &newValue) {
        receiver->updateValue("senderValue", newValue);
    });

Relaxed Constant expressions

C++11 came with the new constexpr keyword. Qt 4.8 has added a new macro Q_DECL_CONSTEXPR that expands to constexpr when supported, and we have been using it for many function when possible in Qt 5.

C++14 is relaxing the rules of what is allowed in a constexpr. C++11 rules were only allowing a single return statement, and could only be applied on const functions. C++14 allow pretty much any code that can be evaluated at compile time.

/* This function was not valid in C++11 because it is composed of several statements,
 * it has a loop, and a local variable. It is now allowed in C++14 */
constexpr int myFunction(int v) {
  int x = 1;
  while (x < v*v)
    x*=2;
  return x;
}

Member functions declared as constexpr in C++11 were automatically considered as const. It is no longer the case as non-const function can also be constexpr.
The result of this change is that constexpr member functions that were not explicitly marked as const will change const-ness in C++14, and this is a binary incompatible change. Fortunately in Qt, all Q_DECL_CONSTEXPR member functions were also explicitly declared as const to keep binary compatibility with non C++11 code.

So now we can start annotating non-const functions such as operator= of many classes. For this reason, Qt 5.5 will come with a new macro Q_DECL_RELAXED_CONSTEXPR which expands to constexpr when the compiler is in a C++14 mode. We will then be able to start annotating relevant functions with Q_DECL_RELAXED_CONSTEXPR

Small features

C++14 also comes with a lot of small convenience feature. That do not have direct impact on Qt, but can be used in your program if you enable C++14. We just made sure that tools like moc can handle them.

Group Separators in Numbers

If you are writing huge constant in your code, you can now now use ' as a group separator:

    int i = 123'456'789;

Binary literal

In C++ you can write your number in decimal, octal (starting your number with 0), hexadecimal (starting with 0x). You can now also write in binary by using the 0b prefix.

    int i = 0b0001'0000'0001;

Automatic return type detection

If you have an inline function, you can use auto as a return type, and you do no longer need to specify it. The compiler will deduce it for you

// return type auto detected to be 'int'
auto sum(int a, int b) { return a+b; }

This is, however, not supported for slot or invokable method as moc would not be able to detect the return type

Variable template

You could have functions template or class template. Now you can also have variable template.

template<typename T> const T pi = 3.141592653589793;
/*...*/
    float f = pi<float>;
    double d = pi<double>;

Uniform initialization of structures with non static data member initializers

In C++11, you can use the uniform initialization to initialize a struct that has no constructor by initializing all the members. C++11 also added the possibility to have inline non static data member initiazers directly in the class declaration. But you could not use the two at the same time. In C++14, you can. This code works and do what you would expect:

struct MyStruct {
    int x;
    QString str;
    bool flag = false;
    QByteArray str2 = "something";
};

    // ...
    // did not compile in C++11 because MyStruct was not an "aggregate" 
    MyStruct s = { 12, "1234", true };
    Q_ASSERT(s.str2 == "something");

Reference Qualifiers

This is not a C++14 feature, but a C++11 change. But we only started to make use of this late in the Qt5 cycle and I did not mention it in a previous blog post so I'll mention it here.

Consider this code:

    QString lower = QString::fromUtf8(data).toLower();

fromUtf8 returns a temporary. It would be nice if the toLower could re-use the memory allocated by the string and do the transformation in place. Well that's what the reference qualifiers for member functions are for.

(code simplified from qstring.h:)

class QString {
public:
    /* ... */

    QString toLower() const &
    { /* ... returns a copy with lower case character ... */ }
    QString toLower() &&
    { /* ... do the conversion in-place ... */ }
    
    /* ... */
};

Notice the '&' and '&&' at the end of toLower. Those are references qualifier and let overload a function depending on the reference type of the 'this' pointer, just like the const qualifier let overload on the constness of this. When toLower is called on a temporary (a rvalue reference) the second overload (the one with &&) will be chosen and the transformation will be done in place.

The functions that benefit from the optimisation in Qt 5.4 are: QString::toUpper, QString::toLower, QString::toCaseFolded, QString::toLatin1, QString::toLocal8Bit, QString::toUtf8, QByteArray::toUpper, QByteArray::toLower, QImage::convertToFormat, QImage::mirorred, QImage::rgbSwapped, QVersionNumber::normalized, QVersionNumber::segment

Changes in the standard library.

C++11 and C++14 have added a lot of feature to the standard library, competing with many of the features of QtCore. However, Qt makes little use of the standard library. In particular, we do not want to have the standard library as part of the ABI. This would allow to stay binary compatible even when the standard library is changed (example libstdc++ vs. libcpp). Also, Qt still supports older platforms that do not have the C++11 standard library. This really limits our uses.

Yet, Qt5 deprecated its own algorithms library and is now recommending to use the algorithms from the STL (example, std::sort instead of qSort).

Conclusion

It may still take some time before you can use those features in your project. But I hope that, by now, you started using C++11 features like many others projects did (Qt Creator, KDE, LLVM).

MSVC will enables C++14 by default with their new compilers, but clang and gcc require a special compilation flag (currently -std=c++1y). With qmake, you can enable your project to build with C++14 since Qt 5.4 by using this option:

CONFIG += c++14

What's New in Qt 5.4: The QStorageInfo Class

In this blog post, I will cover a new class introduced in Qt 5.4.0: QStorageInfo. This post is based on a Lightning Talk I gave at Qt Developer Days 2014 in San Francisco.

Overview

The QStorageInfo class provides information about mounted filesystems, also known as volumes. It allows retrieving information about a volume's storage space, mount point, label and filesystem name. New in the Qt 5.4.0 release, QStorageInfo is part of the Qt Core module.

Endocode is hiring an Assistant to the Board

If you are a recent or about to graduate in a Bachelor’s or Fachhochschule degree in business studies, Endocode might be looking for you! We are hiring an assistant to the board. Admittedly, the job is quite a challenge. It gives a sneak peek into all aspects and functions of managing a company. It does not require much experience, but it requires good training and a passion for learning and problem solving. The responsibilities include supporting management processes like board meetings and negotiations, and also some administrative work for relaxation.

Endocode

One interesting detail about the job is that it is ideal for gaining management and leadership skills before beginning a Master’s degree. I was told not many companies are offering interesting jobs for Bachelor graduates – well, we do! If you are interested, the details are on Endocode’s job page. Feel free to pass it on to your student and graduate friends. The deadline for applications is December 7.


Filed under: Coding, CreativeDestruction, English, FLOSS, KDE, OSS, Qt

HsQML 0.3.2.0 released: Enters the Third Dimension

Last night I released HsQML 0.3.2.0, the latest edition of my Haskell binding to the Qt Quick GUI library. As usual, it's available for download from Hackage.

HsQML allows you to bind declarative user interfaces written in QML against a Haskell back-end, but sometimes you can't just let QML hog all the graphical fun to itself. This latest release allows you incorporate 3D (OpenGL) graphics rendered from Haskell into your QML scenes using the new Canvas module.

The screenshot below shows off the OpenGL demo in the samples package. The colourful triangle is rendered using the regular Haskell Platform's OpenGL bindings, but HsQML sets up the environment so that it renders into a special HaskellCanvas element inside the QML scene. If you run the actual program you can see it being animated too, moving around and changing colour.


This release also adds the Objects.Weak module which allows you to hold weak references to QML objects and keep track of their life cycles using finalisers. The new FactoryPool abstraction uses these primitives to help you efficiently keep track of instances you've created, especially for when you need to fire change signals on them for data-binding.

London Haskell User Group

I've been fortunate enough to get a speaking slot at the London Haskell User Group and will be giving a talk on Building Pragmatic User Interfaces in Haskell with HsQML on the 26th of November. Please feel free to come along and watch. You can RSPV on the group's meet-up page.

The talk should be videoed and materials will be available online afterwards.

release-0.3.2.0 - 2014.11.13

* Added OpenGL canvas support.
* Added weak references and object finalisers.
* Added FactoryPool abstraction.
* Added To-only custom marshallers.
* Added Ignored type.
* Relaxed Cabal dependency constraint on 'text'.

Applying Scrolling and Eliding Text in a Natural User Interface

We recently made a presentation at the Qt Developer Days conference in San Francisco, entitled Make Your Content Shine: Design Choices for a Qt Touch Kiosk. In the presentation we talked about numerous issues related to content display in our touchscreen kiosk product, ViewPoint and explained the best practices that we used to solve those issues. In this post, we are going to focus on a couple of issues with scrolling and eliding text. 

Tasuku Suzuki is the second Qt Champion


QtChampion_logo_72dpi_RGB_color

Last week in the Americas Qt Developer Days, our second Qt Champion was announced.

Tasuku Suzuki, who has been working hard with the Japanese Qt community has earned the Qt Champion title.

Suzuki-san got his first introduction to Qt when as a student back in 2002 he needed to make a UI for a scientific simulator he had written as part of his studies. He tried out several different toolkits and found Qt best suited for his needs.

After that Suzuki-san got more involved in Qt, when  he joined Trolltech in 2006, as a local technical sales support person for Japan. Suzuki-san and his colleagues did a lot of work to get Qt more known locally in Japan. They at some point translated the whole Qt website to Japanese, to make it more accessible. He was also heavily involved in making the Japanese Qt Developer Conferences happen in 2009 – 2011.

Qt_Dev_Tokyo_2011

More recently Suzuki-san has been heavily involved in the Qt Meetups in Japan. The meetups originate from 2010, when @vivisuke started having Qt meetups in his home city. The meetup activity spread inside Japan and soon there were quite a lot of separate meetups in different cities. In 2012 these meetups joined to form the Japan Qt Users’ Group. Around this time Suzuki-san was already active in the Tokyo meetup and the community agreed that he could take over organising the Tokyo meetups.

The format of the meetups in Japan varies, but Suzuki-san has changed the format from a presentation style event to a more active coding event. Everyone can come to the meetup and code, study and ask questions on Qt. These meetups have been happening continuously every month since January 2013, and have attracted new developers to Qt too.

One of the fun details in the meetups is the Qt Sweets Division with @hermit4, whose mission is to provide snacks for the meetups. The results are pretty impressive (cake, choclate and cake 2).

As part of the meetups, Japanese developers have contributed code and bug reports to the Qt project. Suzuki-san has also helped in this, as the language barrier is a problem for many Japanese developers.

Suzuki-san codes himself too, he has worked on different things, including Japanese text input for Qt based platforms.

Another interesting project Suzuki-san is working on, is silk- Simple and flexible web framework. Silk is a Qt project that makes it possible to write server-side code with QML and JavaScript. It comes with everything needed to get running fast with Qt on the server.

Suzuki-san has also contributed code to Qt for several years, and has several contributions to his name.

A package of goodies is on it’s way to Japan, and a one year Qt Professional license has been given to Suzuki-san. I would like to congratulate Suzuki-san on his new title as Qt Champion!

New service: Fix My Qt Bug!

FixMyQtBug2

Need a fix for a Qt bug? Look no further…

At KDAB, we know that fixing bugs in Qt requires resources, deep knowledge of Qt in various use cases and the right tools. Sounds simple enough but can you afford to take the time to do it yourself? Taking part in hundreds of our clients’ Qt projects around the world, embedded as well as desktop, we have come in contact with all types of Qt bugs. To help you save time and money – we are now making that experience available to you, for a fixed price and with a fast turnaround time.

  • Just send your application or a standalone test case to us
  • You will receive a fix in return
  • We’ll even take care of the demanding process of having it included in Qt

A fix for only 7.500 Euro

  • We offer this service at fixed price, so there will be no surprises *
  • After the initial evaluation we can let you know when the fix will be ready
  • We will work on having the fix included in Qt at no extra cost
  • And if for any reason your Qt fix cannot be included in Qt, we’ll even maintain it for you **

Contact us now at:

Curious about our latest fixes?
Go to: https://codereview.qt-project.org/#/q/ownerin:%22CLA+KDAB%22+status:merged+message:Task-number,n,z

* Disclaimer: We reserve the right to reject a bug fix request if the issue is deemed technically insurmountable or would cause disproportionate effort. Customers will be informed of such cases as soon as the evaluation part of the process is over.

** Maintenance of your fix is only included until the next major Qt version is released. Due to the nature of the open-governance process of a Qt contribution, we cannot guarantee when upstream inclusion will happen Additional maintenance purchase is possible. Contact us to request a tailored quote.

The post New service: Fix My Qt Bug! appeared first on KDAB.

Documentation now up for testing in doc.qt.io


Hello,

We have been working on transferring Qt documentation under qt.io and would like to have your feedback on the work so far. All improvement suggestions are welcome. We have a meta-bug opened on the Qt bugtracker where you can add your findings.

The new documentation can be found at http://doc.qt.io/

So what has changed?

–          New layout and style to match qt.io style
–          New documentation publishing process (this is mostly for the benefit of the documentation team)
–          All documentation will be (eventually) transferred under the same location

The upcoming Qt 5.4.0 release will see the Qt 5.4.0 documentation only on the qt.io site, along with downloads.

The other parts of the documentation will also move to the new site in due time. However with that we need to make sure that we have working redirects in place. The web is full of links to the documentation and we want to make sure people don’t end up on a 404 page. So we are not hurrying the move, the redirects need to go right on the first try.

But now we are looking forward to your comments on the new look and feel of the documentation!

Help Qt Continue To Reign Supreme | Vision Mobile 8th Developer Economics Survey


Our friends at Vision Mobile have launched their Developer Economics 2015 Q1 survey to track developer trends across platforms and dev tools – as well as investigate the emerging IoT market. Of course we want Qt to reign supreme, so make sure you let your voice be heard!

DE8-illustration

Take the 10-minute survey and talk mobile trends  – Do you see more opportunity in Wearables, Smart Homes or Connected Cars? Who’s making money from apps – and how? Which are the must-have tool categories for developers? Is the web vs. native debate still relevant?

The key findings will become available in the form of a free research report in February. Aside from contributing to the research, you will also get a chance to win some great prizes, including an iPhone 6, a Google Nexus 5,  a Lumia 930, an Oculus Rift DevKit, and a Samsung Gear Smartwatch!

Get involved and don’t forget to help us spread the word via the Qt community.

Let’s join forces and support Qt!

QMetaType in plugins

I've learned that for some uses QMetaType just does not work.

Imagine that you want to read types of parameters of some signal or slot of QObject. You also know that all parameters to this method are pointers to QObject-based types. The best way to do that is to:

  1. register your type with qRegisterMetaType<QObjectDerivedType>
  2. read parameter meta type id with QMetaMethod::parameterType(int)
  3. get QMetaObject of this parameter with QMetaType::metaObjectForType(int)
In most cases it works. But not when QObjectDerivedType lives inside a plugin that is dynamically loaded and unloaded several times during program execution (and this whole sequence is run on each plugin load).

On first load everything works perfectly. On second (or third or next, it is rather random and probably depends on allocation patterns in application) your QMetaObject from point 3 is invalid and using it causes access violation. Why? QMetaType remembers address of QMetaObject for each QObject based class pointer per program execution. On load a new QMetaObject is constructed for each type that lives in plugin. And on unload its memory is freed. In result the stored pointer just must to be invalid.

Maybe I missed something, but I was not able to get it to work properly. My solution is to use custom paramter-QMetaObject mapping instead of relying on QMetaType. It is based on QMetaMethod::parametrTypes() method that returns type name and a map of type-name to QMetaObject pointer that is created on each plugin load and passed around. I'm not very happy with this solution, because it is prone to namespace issues and it does not allow usage of types that are no preregistered in plugin (on the other side, QMetaType has the same problem). Hopefully C++ reflection will become real some day.

But there is one more thing that makes me happy - replacing first solution with second in my dependency framework Injeqt took some time and required non-trivial changes in library. But API and ABI remained the same - there was no need to recompile Kadu 2 to work with new version. It means that my usage of private and public interfaces, pimpls and anonymous namespaces is at least proper. This also closed last bug that blocked 1.0 release. This means I can now prepare beta 0.9 and focus on developing Kadu (also to test if Injeqt is really ready to be released).

Qt Creator 3.3 beta released


We are happy to announce that we released Qt Creator 3.3 beta1 today.

editordraganddrop

It comes with enhanced support for splitting editors and additional editor windows. You can now drag & drop editors between splits by dragging the new file type icon, next to the document drop down (see screenshot). Hold the Ctrl key (or Option key on OS X) to open another editor on the same document, instead of moving it. The navigation views (such as Projects and Open Documents) also support dragging files onto splits. Dropping files from the system onto a Qt Creator window now will also open the file in the appropriate split.

It is now possible to specify environment variables to be used with specific kits. Display names of kits and Qt versions can contain variables like %{Qt:Version}, which are automatically filled with the corresponding values. We also added a check box to select and deselect all kits when setting up projects.

Opening QMake projects is now also done asynchronously, like the reparsing that is done when .pro or .pri files change. You can now add files to Qbs projects via the context menu on the Projects view.

The QML Profiler got support for reordering, showing, and hiding categories in the timeline. Also, you can attach notes to events, that are then exported together with the profiling data and can be shared with others.

When pressing the Enter key while the text cursor is within a C++ string literal, the string is now (optionally) split and continued on the next line, adding the necessary quotes for you automatically. We also added a little refactoring action for converting connect() calls to use the new connect style in Qt 5.

For Android development we added support for the Gradle build system.

For users of the Professional or Enterprise edition, we added experimental support for running the Clang Static Analyzer on your projects, as a new tool in Analyze mode. The scene graph events category in the QML Profiler has been significantly improved and will now visualize the time ranges of all scene graph related events instead of showing them as a list of numbers. You can also see input events in the QML profiler now, in a separate category.

We fixed many more bugs and made improvements, such as enhancing the appearance of Qt Creator on high DPI displays, adding a list of open windows to the Window menu, and adding an optional sidebar with Contents, Index, Bookmarks and Search views to the external help window. See our change log for a more complete list of changes.

You find the opensource version on the Qt Project download page, and Enterprise packages on the Qt Account Portal. Please post issues in our bug tracker. You also can find us on IRC on #qt-creator on irc.freenode.net, and on the Qt Creator mailing list.

Note: With Qt Creator 3.3 we drop support for compiling Qt Creator with Qt 4. The minimal required Qt version to compile Qt Creator itself is currently Qt 5.3.1. This does not affect your own projects, of course, we still fully support development of Qt 4-based applications with Qt Creator.

An update on OS X Code Signing

by Morten Johan Sørvig (Qt Blog)


There has recently been updates to the OS X code signing process. These updates also affect Qt applications signed for distribution, both on and outside the App Store.

OS X 10.9 Mavericks introduced version 2 signatures. As of OS X 10.9.5 and 10.10 Yosemite, v2 signatures are now required. We’ve recently spent some time updating Qt to be v2 compliant and Qt 5.4 will be the first compliant release. This includes patches to qmake and the macdeployqt deployment utility. Manually correcting the signing errors is possible if you are using an older version of Qt.

The Apple documentation is quite comprehensive on this topic, in particular see Code Signing Guide and TN2206 OS X Code Signing In Depth. The Qt tracking bug for this issue is QTBUG-32896.

Required changes to Qt

The required changes falls in three categories: updating the framework and application bundle structure, updating Info.plist contents, and special Qt Quick imports handling.

Updating the framework and application bundle structure

  • The Info.plist file must be placed in Versions/5/Resources/Info.plist.
  • Updated symlink structure: “Current” symlink points to the actual version (“4” or “5”).
  • The framework must be “clean” at code signing time, with for example no QtCore.prl at the root. This is currently enforced by macdeployqt.

As an example, the QtCore.framework structure should look like this:

QtCore.framework/
    QtCore -> Versions/Current/QtCore
    Resources -> Versions/Current/Resources
    Versions/
        Current -> 5
        5/
            QtCore
            Resources/
                Info.plist

And a typical app bundle:

foo.app/
    Contents/
         Frameworks/
             QtCore.framework/
         Info.plist
         MacOS/
             foo
         PkgInfo/
         PlugIns/
         Resources/

Update Info.plist contents
The Info.plist files as generated by current qmake versions are missing some required keys:

  • CFBundleIdentifier (“org.qt-project.QtCore”)
  • CFBundleVersion (“5.4.0″)

Split Qt Quick imports into code and data in the application bundle

This is a v2 code signing requirement which affects applications with Qt Quick imports that contain both binary code (.dylib) and data (.qml) files.

Previous versions macdeployqt would deploy all files to Resources/, but as of v2 binary code in Resources/ is now prohibited. This is solved deploying .dylib files to PlugIns/ and then placing a symlink in Resources/ pointing to the .dylib.

Code signing flow and checkpoints

The following outlines a typical code signing process, with notes on where a current 4.8/5.3 Qt install may fail. The focus is on using the command line tools. Code signing using Xcode is possible but not covered here. The process is incremental: Some steps can be verified by any developer locally, while others require developer account admin access.

1) Signing and verifying the app bundle.

    sign: codesign --deep foo.app -s MyCertificate
      or: macdeployqt foo.app -codesign=MyCertificate
    verify: codesign —verify foo.app

The -deep option signs the app bundle recursively, including contained frameworks. While convenient to use, –deep is documented for “emergency repairs and temporary adjustments only“. As of Qt 5.4 macdeployqt has a -codesign option that recursively signs the app bundle without using –deep.

Common errors at this stage include “bundle format unrecognized, invalid, or unsuitable”, and/or “bar.dylib: code object is not signed at all”, which indicates that the framework structure is not correct or that some contained binary was not signed.

At this point which certificate you use does not matter. You can use a self-signed one created in Keychain Access for development and testing purposes.

2a) Distribution outside the App Store
Verify that GateKeeper will allow the app:

    spctl --assess --type execute foo.app

spctl outputs nothing on success. Common errors include “Rejected”. The bundle must be signed with the correct “Developer ID Application” production certificate for this check to work. The certificate is available for download to the Team Agent in the Mac Dev Center.

2b) App Store distribution
May trigger additional errors:

    ERROR ITMS-9000 The application bundle contains a tool or framework
    foo.app/Contents/Frameworks/QtCore.framework that is missing the
    bundle identifier.

This is currently a pending task for Qt 5.4. You can edit the plist files manually and add a bundle identifiers.

Availability

The updates are/will be available for three Qt versions:

  • 5.3 source code (not packaged)
  • 5.4 release. The updates will be be a part of the 5.4 source and binary release.
  • 4.8 patches: https://codereview.qt-project.org/#/c/95572, with the intention that this will be a part of a future 4.8.x release.

TODO list

The fixes for some issues are currently in progress:

  • Adding CFBundleIdentifier for the Qt frameworks
  • Changing the location of .prl files

Do you have corrections or additional info? Hit the comments section!

Notes from a UX Pro Over a Cup of Joe: Mental Models

Welcome back to the coffee corner!  

I hope that you’re doing well and enjoying your user experience (UX) rock star status on any project you may be working on, no matter your role. Today, we’re going to be chatting about Mental Models - what they are, why we should care about them and how we can leverage them to inform design thinking.

Qt + CMake + code coverage

Yesterday I was working on getting reports on code coverage for Injeqt library. I've found several tutorials on the internet, but every one of them was missing a detail or two.

So here is what I've come with:

1. Update compiler and linker flags in CMakeLists.txt file of your tests:

set (CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Wall -W -g
-fprofile-arcs -ftest-coverage -O0")
set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -W -g
-fprofile-arcs -ftest-coverage -O0")
set (CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS}
-fprofile-arcs -ftest-coverage -O0")
2. Link each test with gcov library:
target_link_libraries (test-target-name gcov)
3. Add new target for extracting coverage data:
add_custom_target (coverage
COMMAND ${CMAKE_CURRENT_SOURCE_DIR}/coverage.sh
WORKING_DIRECTORY ${CMAKE_BINARY_DIR})
4. Insert coverage.sh script into directory of CMakeLists.txt:
#!/bin/bash

lcov --capture --directory . --output-file coverage.info
lcov --directory . --output-file coverage.info \
--remove coverage.info "/usr/*" "*.moc" "test/*"
genhtml coverage.info
First lcov invocation will capture all data from previously executed tests. Second will remove useless data like coverage of generated moc files or of standard library headers and tests themselves.

5. Run tests and coverage:
make test
make coverage
6. Enjoy nice HTML coverage report.

Injeqt got 90,4% of lines coverage on first try! I hope to make it even better today.

KDAB contributions to Qt 5.4: qmllint

One type of bug I see very often comes down to syntax errors in QML and JavaScript files. Most of the time these errors are simple typos; however, they creep in, go unnoticed by continuous integration and sometimes reach production — especially on delayed loaded components.

I like fixing bugs, but what I love even more is not fixing them, so I wrote a command line tool that can easily be integrated into our CI system so we can nip them in the bud at build time.

Enter qmllint: a command line QML syntax checker. Example usage:

$ qmllint ClickableImage.qml
ClickableImage.qml:17 : Expected token `numeric literal'

Verifying all files:

$ find -type f -name \*qml -exec qmllint \{\} +
./qml/SettingsPage.qml:35: Unexpected token `if'
./qml/AboutPage.qml:35: Expected a qualified name id

qmllint comes with Qt 5.4 and lives alongside other Qt tools.

Furthermore, I would also recommend using other linter tools in your project, such as json_verify or xmllint. Do not do manually what could be automated by the build system!

Caveats

qmllint cannot catch semantic errors. There are cases where QML files are syntactically correct but have other types of problems:

Bar.qml:1 TypeFoo is not a type
Bar.qml:2 module "QtQuickControls" is not installed
Bar.qml:6:9: QML Rectangle: Cannot anchor to an item that isn't a parent or
sibling.

There are no plans on my part to make this tool smarter, I like the “do one thing and do it well” philosophy, so it is finished. Checking for these kinds of mistakes is also very difficult, f.i. because we would need to depend on the QML context of a running application.

But don’t worry, my next blog post will address automating semantic validation, so stay tuned!

The post KDAB contributions to Qt 5.4: qmllint appeared first on KDAB.

Say hello to the first Qt Champion!


QtChampion_logo_72dpi_RGB_colorLast week our first Qt Champion was awarded his title in Berlin at the Qt Developer Days Europe. Samuel Gaist (SGaist on the forums) is now a Community Builder Qt Champion.

If you have visited the Qt Forums you probably have seen Samuels answer to some question. He is, and has long been, the most active contributor on the Forums, topping the most active contributors list week after week.

Aside from Samuels sheer amount of activity on the forums, his other distinguishing feature is his positive attitude to all questions. He sees the positive wibe as a feature of the community and wants to keep the positive energy flowing by contributing himself. in Qt people are willing to help each other with questions and problems, so it is one form of giving back.

Samuel had heard of Qt as he had used Linux and the KDE desktop about ten years ago, but he learned about Qt properly during his studies at the “HES-SO Valais Wallis” school. At the start of 2012 Samuel joined the Qt project forums and hasn’t looked back since.

The biggest Qt project Samuel has up-to-date worked on has been the AgiScan film scanning software, which he worked on at Edeltech Ltd. He also did a talk at the Qt Developer Days Europe 2014 about his experiences on the project.

SgaistIn the last year or so Samuel has also started contributing code to Qt. It all sterted with a question on the forums about a bug in QFileDialog on Mac OS X. Samuel figured he could actually fix the bug and went ahead and answered the question and fixed the bug. From then on Samuel has taken to occasionally looking at the Qt bug reporting system and finding places where he can help, like bug fixing, documentation updates and code cleanups. Lately Samuel has also done some feature work with help from other contributors.

Samuel has found that the diverse background of people involved in the Qt project makes for good discussions, be it on the forums, contribution reviews or the mailing lists. Talking and getting feedback makes for better contrbutions.

In addition to the nice cap and t-shirt, Samuel will be receiving a Qt Professional license for the next year.

Please join me in congratulating our first Qt Champion, Samuel Gaist!

Qt 5.4 Beta Available


I am extremely happy to announce that Qt 5.4 Beta is now available for download. There are a lot of new and interesting things in Qt 5.4 and I will try to summarize the most important highlights in this blog post.

Powerful Web Offering with Qt WebEngine

As the importance of HTML5 has grown we want to provide the best support for HTML5 within the Qt technology offering. The Qt WebEngine, a long-term R&D project based on the Chromium web engine has now reached fully supported version on desktop and embedded platforms.

Qt WebEngine provides a convenient API for both Qt Widgets and Qt Quick for using the Chromium web engine. Besides plain web viewing purposes Qt WebEngine takes full benefit of the whole Qt graphics stack integration allowing you to mix and overlay native Qt controls with web contents and OpenGL shaders. Of course, the fact that Qt provides a full application framework around the web engine makes Qt WebEngine truly an unparalled web engine API.

The new Qt WebChannel module acts as the bridge between QML/C++ and HTML/JavaScript allowing you to expose QObjects into the web context.

For platforms that do not allow distribution of Qt WebEngine as well as use cases where a full-blown web engine is not needed Qt 5.4 will introduce a technology preview of a new module called Qt WebView. It supports embedding the native web engines of the underlying operating system into Qt, and is currently available for Android and iOS. Because of this, Qt WebView also gives a convenient light-weight solution for simple web document integration. Qt WebView will be available with Qt 5.4 final as a separate add-on.

Qt 5.4 also contains Qt WebKit. It is still supported, but as of Qt 5.4 we consider it done, so no new functionality will be added to it. We are also planning to deprecate Qt WebKit in future releases, as the new Qt WebEngine provides what is needed. In most use cases, migrating from Qt WebKit to Qt WebEngine is rather straightforward.

Complete Support for Windows Runtime – Use Qt for Windows Store Apps

The Windows Runtime port of Qt saw its first supported beta release with Qt 5.3. With all the feedback we have improved the port a lot and implemented most of the missing APIs. With Qt 5.4 WinRT is now fully supported as a primary deployment platform.

Qt 5.4 provides support for most of the Qt functionality on WinRT, including for example Qt Quick and Qt Quick Controls, Qt Quick Compiler, Multimedia, Positioning, Network (also SSL/TLS), Core and GUI. With Qt for WinRT port you are now able to target Windows Store Apps: Windows Phone 8.1 and above and Windows tablets with the Modern UI and publish your applications in the Windows Store.

New License Terms – Introducing LGPLv3

As announced earlier, the open-source version for Qt 5.4 is also made available under the LGPLv3 license. The new licensing option allows us at The Qt Company to introduce more value-add components for the whole Qt ecosystem without making compromises on the business side.

Through this dual-licensing model, with Qt 5.4 timeframe we are introducing technology previews for the light-weight cross-platform WebView and the 3D Canvas. Similarly the new Qt WebEngine and Android style are available only through a commercial Qt license and under GPL and LGPLv3 for the open-source users.

To find out the best licensing option for you, please see the new licensing page and the downloads page.

HighDPI Support, Dynamic GL and Other Improvements for Windows Users

In addition to WinRT, Qt 5.4 brings many other improvements to Windows users. Qt 5.4 brings support for High DPI displays. A typical 4K monitor may have 3840×2160 pixels, a logical resolution of 192 DPI, whereas older monitors have around 1920×1080 pixels at 96 DPI. Qt maintains the font point size on a 4K monitor, resulting the text being drawn as indented for a 96 DPI layout. With Qt 5.4 we have especially worked for enabling the HighDPI support for Windows – in addition to improving it in other platforms such as Mac and X11.

HighDPI support is still considered experimental in Qt 5.4, and needs to be enabled via an environment variable. If you are interested in the HighDPI support, check out the overview documentation.

Qt 5.4 brings capability to dynamically select during the application startup whether to use ANGLE or OpenGL on Windows. It is possible to use either opengl32.dll or ANGLE’s OpenGL ES 2.0 implementation in Qt applications without the need for two separate builds of the binaries. This significantly simplifies the task of creating Qt Quick applications for Windows PCs. Dynamic GL switching is not yet enabled in the prebuilt Qt 5.4 Beta binaries. In addition to these, there is a large number of smaller improvements and bug fixes for the Windows port in Qt 5.4.

Other Graphics Improvements

There are quite many important graphics improvements in Qt 5.4 in addition to improved HighDPI support and dynamic GL switching on Windows. One of the most important ones is QOpenGLWidget, the modern replacement for the old QGLWidget class from Qt 4. QOpenGLWidget is a new widget for showing OpenGL rendered content, which can be used like any other QWidget. This also allows us to deprecate old Qt OpenGL module, as everything it does and more is now provided by the other modules.

Qt 5.4 also brings new QQuickRenderControl API, which allows efficient rendering of Qt Quick 2 scenes into framebuffer objects. The contents can then be used in arbitrary ways in Qt-based or 3rd party OpenGL renderers. With Qt 5.4 you can also adopt and wrap existing OpenGL contexts in QOpenGLContext. This improves the ability to embed Qt content for use in other rendering engines. In addition to other new graphics APIs Qt 5.4 brings convenient QOpenGLWindow and QRasterWindow classes as well as introduces support for 10-bit per color channel images.

QOpenGLContext is now able to adopt existing native contexts (EGL, GLX, …). This allows interoperability between Qt and other frameworks, such as game engines. Read more from this blog post.

Bluetooth Low Energy

Qt 5.4 provides a technology preview implementation of Bluetooth Low Energy, which allows communication to a lot of smart sensors and gadgets such as wearables. It is initially supported for BlueZ 4 and 5 on Linux only – support for platforms such as iOS and Android will be added in upcoming Qt versions. With Qt 5.4 we implement the BTLE central role as per Bluetooth spec 4.0, i.e. at the moment you can only create the client for BTLE.

If you are interested in BTLE, please check the Qt Bluetooth LE Overview. We are very much interested in receiving feedback from users to be able to move beyond tech preview state.

Faster Startup, Smaller Deployment Packages and Native Style for Android

We have worked actively to improve support for Qt on Android and there are many important new Android specific items in Qt 5.4. There is now support for QML import scanner, which helps in optimizing the package size for deployment. With the pre-generated assets cache that improves application start-up time introduced in Qt 5.3 and the Qt Quick Compiler available in the commercial editions, it is possible to start Qt for Android applications in a breeze.

On the user interface side we have extended the styling capabilities of Qt Quick and added support to Android style, which enables native look for Widgets and the Qt Quick Controls on Android. In previous versions of Qt it was possible to style Widgets to look native on Android only if one used Ministro. Now both the Widgets and Qt Quick Controls, i.e. buttons, sliders, progress bars and other controls and widgets you use in your application, will look native on Android by default.

iOS Improvements

Support for iOS is improved with Qt 5.4 which contains many important fixes for iOS 8 and Xcode 6. In addition to smaller improvements and bug fixes there are also some new features such as a touch-based text selection model. Instead of the previous desktop like approach (press-and-drag), you can now do press-and-hold to select text. Qt will give you selection handles that can be dragged and a popup text edit menu, like with native apps. The edit menu can also be customized from Qt Quick controls.

Work has also been started to improve usage of native menus in general. In addition to the edit menu mentioned above, Qt 5.4 now uses a native pickerview menu for many of the Qt Quick Controls that have a menu attached. A lot of work has also gone into improving and stabilizing code that deals with window, screen and orientation geometry, and virtual keyboard management.

Support for Mac OS X 10.10, Code Signing and other Mac Improvements

Our Mac users get greatly improved support for new Mac OS X 10.10 Yosemite with Qt 5.4. We have worked hard to improve and fix styling and other issues with Mac OS X 10.10 for Qt 5.4. Applications created with earlier Qt versions work on the upcoming Mac OS X 10.10, but there may be some issues in styling depending on your application. In addition to OS X 10.10 support we have fixed many customer reported Mac bugs in Qt 5.4 Beta – and we continue to provide more fixes still before the final is out.

One very important improvement in Qt 5.4 is support to new code signing style required by OS X 10.10 (and 10.9.5) for applications published in the Mac AppStore. These are still partially work in progress, but the initial support is included already to the Qt 5.4 beta release and polished for the Qt 5.4.0 final release.

Wacom tablets, Wayland, Updated Qt Creator and Other Items

Support for Wacom tablets has been improved and unified across platforms in Qt 5.4 with the help and support by KDE/Krita developers. QTabletEvent now has information about which stylus buttons are pressed, rotation and tangentialPressure have consistent ranges across platforms and proximity events include the type of stylus or other tool in use. With these changes there is one less obstacle to upgrade to Qt 5.

Qt 5.4 now includes the Qt Wayland module. This enables you to run Qt applications on Weston, the reference compositor for Wayland. Weston and Wayland support is still in its early stages, and does not yet provide a full featured desktop environment that you get with Windows, Cocoa and xcb. However, Weston and Wayland already provide a light-weight windowing system that might be desirable to use in the embedded space. Qt Wayland module is delivered as source code only. We will continue our focus on improving our support for Wayland in Qt especially for device creation.

Qt 5.4 Beta packages include the updated Qt Creator 3.2.2 providing improvements for example to Xcode 6 and iOS Simulator usage.

I have listed some of the highlights of Qt 5.4, but many things are not mentioned. For more details, please check What is new with Qt 5.4 – or take Qt 5.4 Beta for a spin and see for yourself.

Get Qt 5.4 Beta Today

Qt 5.4 Beta is now available, for existing Qt users, through your Qt Account, or from the Qt Project download server for open-source packages. Please download, try it out and send us feedback through the mailing lists or bug reports.

Update on the qt.io website work


Hello, some news from the new qt.io website work we are doing.

First, thank you to everyone who provided feedback on the new qt.io site, we appreciate all the comments we have gotten on different channels. And while every comment will not make it as a change to the site, we do evaluate every single one of them and see if something needs to be tweaked.

Please don’t expect instant changes, we have a pretty long backlog including big items like: “How do we solve the problem of using a unified Qt account for logging into all the services we provide on the web?” A bit of patience on your part is appreciated.

That said, the documentation pages are next on the list of things moving to qt.io. One target of moving the documentation is to bring all the open source and commercial documentation under one landing page. That means that you will find all relevant documentation from one location, no more jumping between two sites.

During the documentation move, we will be retiring the docnotes feature on qt-project.org. While there have been some very high quality notes from the community, the feature has mostly gone unused. The effort to maintain the docnotes feature is not worth the benefit that it brings.

One thing we have on the list of things that could be simplified, is contributing to documentation. The issue with contributing to the documentation is that the documentation is built from the Qt source itself, thus any changes to the documentation need to go through the same process as code contributions. And the contribution process might seem a bit complicated to people who are not familiar with it. We haven’t figured out how to best do this, so it’s still in the backlog. If you have ideas on how we could make contributing to the docs easier we would appreciate if you shared them with us.

The schedule for the documentation page moves to their new home on qt.io is before the Qt 5.4.0 release.

We will also be moving all downloads to qt.io with the same schedule as the documentation. The upcoming Qt 5.4 beta will be available on both the qt.io and qt-project.org sites, but now that the qt.io download page has been updated based on the feedback we got (thank you!) we hope that you already move over there for the downloads.

The wiki will be moving over to qt.io after the documentation and downloads as well. The new wiki will be a MediaWiki instance. With the wiki, the biggest amount of work is not setting up the new wiki, but rather moving the content over to the new wiki. We have a lot of external links coming into the wiki, and we need to have pointers to the new wiki from the current one. A rough estimate is that we need to move between three and five hundred pages to get decent coverage in the new wiki. To do this we will be asking for your help in copying content over and marking pages as moved. But more on that in another post later when we have the new wiki up and running.

As for the forums, those are on the list after the wiki. No fixed schedule for that yet, as we need to figure out how to move the almost 50 000 discussion threads we have on the forums.

We’ll be making more posts on how the site move is going as work progresses here.

Removal of the Ubuntu-Touch code from Trojita git

Some of the recent releases of Trojitá, a fast Qt e-mail client, mentioned an ongoing work towards bringing the application to the Ubuntu Touch platform. It turns out that this won't be happening.

The developers who were working on the Ubuntu Touch UI decided that they would prefer to end working with upstream and instead focus on a standalone long-term fork of Trojitá called Dekko. The fork lives within the Launchpad ecosystem and we agreed that there's no point in keeping unmaintained and dead code in our repository anymore -- hence it's being removed.

Qt 5.3.2 Update for Device Creation


For creating devices with Qt, we offer a whole toolkit consisting of Qt libraries, pre-built but customizable software stack (Boot to Qt), value-add components and full embedded tooling around the Qt Creator IDE.

Now, It’s time to update our offering by updating the pre-built Boot to Qt software stack with the latest Qt 5.3.2 and upgrade some of the provided value-add components. Also Qt Creator IDE has been updated since our last update. To read more about the whole toolkit for creating devices with Qt see the documentation overview.

Qt 5.3.2 packs a bunch of bug fixes and improvements to functionality based on feedback and reports we have received. Qt 5.3.2 maintains backward and forward compatibility, both source and binary, with Qt 5.3.0 and the latest, 5.3.1, which was released this June. See more from the Qt 5.3.2 release blog post.

Many of our value-add components have been updated as well. The Qt Quick Compiler has gotten it’s first update, Qt Quick Enterprise Controls have been improved by adding the frequently requested Tumbler control and the Qt Virtual Keyboard is now updated to version 1.2 that provides new layouts and features.

Qt Creator IDE has also been updated with a patch release to version 3.2.2. The Qt Creator 3.2.2 patch release contains a few essential fixes for the embedded functionality on top of fixes provided by the Qt Creator 3.2.1 update from about a month ago.

Qt Virtual Keyboard 1.2

The initial version of the Qt Virtual Keyboard was introduced early this year, and version 1.1 before summer. It is a great choice if you are in need of an extendable virtual keyboard on your embedded device, or as part of your embedded application.

It now has no less than 16 different language layouts to choose from: English, German, French, Spanish, Italian, Russian, Portugese, Polish, Finnish, Swedish, Chinese (pinyin) and Arabic were already in place, and now Hindi, Persian/Farsi, Danish and Norwegian (finally!) have been added. You can of course add more yourself. Next up on our roadmap are Japanese and Korean.

The keyboard supports both 5 and 2-way navigation, so you can also enter text through limited input devices, such as scroll wheel or joystick. As you have seen with previous versions, you can change the look of the keyboard, and now it is in addition possible to switch themes during runtime. For now it is only officially supported on embedded Linux,  embedded Android, and desktop Linux, but Windows support is coming up too. The documentation provides more details.

Qt Quick Enterprise Controls 1.2

Finally, the Tumbler is here! The Tumbler control is well-known in mobile user interfaces and much used in all kinds of touch-based devices. Now you no longer need to fiddle around manually with PathView & friends (as fun as it is, though!), but you can just take the Tumbler control and customize it into your needs!

Qt Quick Compiler 1.1

The Qt Quick Compiler, which was introduced with Qt 5.3.1, allows you to compile your otherwise-dynamically-loaded QML files into native code reducing load-time, enhancing performance on non-JITting platforms and making reverse engineering much harder. For embedded users this release brings robustness in form of multiple bug fixes.

Getting Started

Existing licensees for device creation with Qt can download the updated toolkit via Qt account or using their existing online installer. For new users, contact our sales to purchase a license or request a free 30-day trial via our Download page to get started with creating devices with Qt!

We are looking forward to your feedback!

Qt Creator 3.2.2 released


We are happy to announce the release of Qt Creator 3.2.2. This version of Qt Creator mainly fixes compatibility issues with Xcode 6 on OS X. See the change log for a complete list of changes. Also, we added the option to use Qt Creator under the LGPL v3. For more details about this addition, please check out the blog post “Adding LGPL v3 to Qt”.

You find the opensource version on the Qt Project download page, and Enterprise packages on the Qt Account Portal. Please post issues in our bug tracker. You can also find us on IRC on #qt-creator on irc.freenode.net, and on the Qt Creator mailing list.

Animated Blur for Static Images

by author ()

I mentioned before how blurring is a pretty expensive operation so it got me thinking. For dynamic content, we need to do the full thing, and what we have in Qt Graphical Effects is decent, but for static images there are techniques to do it a lot faster.

 

 

We can load images from disk, do a bit of processing, and then be able to dynamically animate from sharp to heavily blurred with close to the same rendering performance as blending a normal image, and with minimal memory overhead. Inspired by articles like this and this, I implemented something I think can be quite useful in Qt Quick. This is done by using custom mipmaps with mipmap bias. A QML module implementing this feature can be found here

 


Below are two screenshots from the test application. The blur ratio is adjusted to keep focus on either the droids in the foreground (topmost) or on the walkers in the background (lowermost). 





Implementation Details 


Mipmapping is normally used to improve performance and reduce aliasing in downscaled textures. In our case, we want to use the mipmap levels to render blurred images instead. Look at the following example:

 



The original image is on the left. Towards the right are the mipmap levels 1, 2 and 3 for this image, generated using glGenerateMipmaps(). The lower row shows the mipmap levels in their original size and the topmost shows the mipmap levels scaled back up to the size of the original image. Using mipmap bias, an optional argument to the texture sampling function, we can pick a higher mipmap level. When combined with GL_LINEAR_MIPMAP_LINEAR, we can interpolate both in x and y and also between the mipmap levels, seamlessly moving from sharp to coarse. However, the default mipmaps give quite blocky results.


The mipmap levels above are created automatically using glGenerateMipmaps(). It is possible to specify each level manually as well. In the following image, I’ve created mipmap levels by scaling the image down with linear sampling (basically 2x2 box sampling), then applied a 3x3 box blur. The process is repeated for each level based on the previous image. It is not a true gaussian blur, but it comes out quite decent. 

 


 

The result is that the mipmap levels are now blurred instead of blocky. Using these mipmap levels and the mipmap bias, we can now select an arbitrary blurryness with a single texture2D() call in the fragment shader. The resulting performance is equivalent to that of blending a normal image, which means this approach is fully doable on mobile GPUs. The mipmap levels adds about 1/3 to the memory consumption, which is quite acceptable. 

 

 

Please note that because of the manual downscaling and box blur, the initial texture upload is significantly slower than a plain upload, so it needs be done in controlled places, like a loading screen or during application startup, to avoid hickups in the animation. For a very controlled setup, one could imagine generating all the mipmap levels offline and just upload them in the application. That would save a bit of time, but makes it a bit less flexible. Note also that mipmapping does not mix with a texture atlas, so each image needs to be a separate texture, which means the blurred images do not batch in the scene graph renderer. That means that while we can have several large images being blurred, we cannot have hundreds or thousands of small ones in a scene and expect to sustain a velvet 60 fps. 


 

So, if you want to incorporate animated blurs of static images into your application or game, have a look at BlurredImage.