Tizen @ QtCS 2013 (part 2)

This is second and last part in a log from the Qt Contributors Summit 2013 (QtCS) written with Tizen in mind. In part 1 I covered Tizen Q&A and some topics related to the Qt frameworks. Today I'd like to share more juicy news about upcoming frameworks, some platforms news and Qt business.

Frameworks Sessions

New QML Elements

dbwilldo CC BY-NC-SA 2.0

It’s useful to have access to global data structures in applications to capture state of the business logic in a form of singleton. In QML it is not different but so far (in 5.1 and before) there were no official means to do that without asking C++ or JavaScript for help. This is going to change with a new notation of a QML singleton based on a new pragma keyword:

// OtherType.qml
pragma singleton
import QtQml 2.0
QtObject {
  property int foo: 3
}

// main.qml
import QtQuick 2.2
import "."
Item {
  width: 20 + OtherType.foo
}

Behavior of the new type is identical to C++ and JSValue singletons. Pragma was used because contributors agreed that the goal is not to do any harm to the sanity of language and readability.

Other elements that would probably come to QML in Qt 5.2 are enums, grouped properties, protected properties (no longer __ prefix is needed!), and pragma strict. Please note that all agreements are so far only verbal.

QML Settings

To make application settings persistent across sessions in Qt Quick require stepping into C++ or using JavaScript a with storage API. Doing that without C++ or JavaScript would be soon possible when the new Settings API arrives to QML. Example use:

// Conf.qml
PersistentSettings {
  property int size
}

// main.qml
Text {
  text: "foo"
  font.pixelSize: Conf.size
}

This topic was first discussed in December.

V4 Engine

During one session Digia Qt Chief Architect/Maintainer Lars Knoll presented a new V4 JavaScript dedicated (read: optimized) for the QML engine. Believe or not but Lars (together with Simon Hausmann) has time to develop the v4 as a replacement for Google's v8.

jurvetson CC BY 2.0

According to Lars v4 has dramatically smaller codebase, lowers memory consumption (v8 is optimized for big apps) and costs of QML property conversions. Other nice benefit is a possibility of compiling QML code which can be also stored in a file. This exactly was on top of my wish list :) Lars explained more ideas behind this development earlier on his blog.

Benefits from these improvements in the Qt for Tizen are rather clear: smaller memory consumption on Tizen phones and Tizen IVI, even better app performance especially those that make more use of JavaScript ie. architecture-independent. And finally, proper means to hide source code for those that want to do that, in a way that cannot be matched by any obfuscation known from HTML-based runtimes.

Platforms Sessions

Qt for Tizen

This session was organized by Tomasz and me. Application's GUI styling was a main topic here, to us somehow a follow up of earlier Qt Quick Controls session. We called for taking next step to separate styling from common application's business logic more deeply where it makes sense. We meant moving the controls' logic to the Style as well, not only the look.

Developers came to conclusion that separation between form factors should be set on right level. For example toolbars on desktop and smartphone are not only different in terms of look and feel but sometimes also in terms of API. For example, Android's context menus act as popups centered on screen but Tizen shows local popups adjusted to the context. There still will be some APIs specific to given mobile platform, accessible eg. via import QtQuick.Controls.Tizen 1.0 but that should be kept at reasonable minimum.

Where possible, native system API could be used by the Qt Quick components but sometimes there’s no reliable way of using it, exposing to Qt Quick's scene. Resulting quality of effects may be unacceptable or there’s no API at all (eg. on iOS) because mobile platforms are very different in this aspect compared to desktop platforms. In such cases authors of a platform style have to just make a copy of bitmaps for use by Qt Quick.

While talking about styles we presented the reworked Touch demo (a gallery of controls) from the qtquickcontrols module and my Twitter sample app being a work in progress. Both apps utilize alpha 2 version of Qt Quick Control Styles for Tizen.

We also covered licensing topics. Some companies sometimes protect assets of their GUI styles as these are means for differentiation, especially important on the fragmented ecosystem of Android. In case of Tizen style assets are safely Apache 2.0-licensed, original Android style is open too but we
re not sure whether it’s safe to make a copy of Samsung Galaxy’s (TouchWiz) style. This topic was summarized by conclusion that ideally, vendors themselves could be invited to deliver and maintain suitable styles to get best possible support for their platforms.

Other platforms

Qt for iOS presented by Tor Arne Vestbø. It’s currently a technology preview for 5.1 and supports Widgets, QML1, OpenGL, Sensors, Network and has basic Xcode support. iOS style for Qt Quick Controls is still a TODO, Qt Creator and Xcode integration is planned.

Qt for BlackBerry. Presented by Vladimir Minenko and others. BlackBerry was a gold sponsor of this Summit. Support for Qt 5 is in the works but so far now Qt libraries and assets have to be bundled with apps. What’s interesting, Qt 5 apps can already be published in the BlackBerry World store.

Qt for Android presented by Eskil Blomfeldt (Digia)

Wayland Support

As you might already know the KDE Plasma Desktop (and Plasma Active) go the Wayland route on devices where it is possible. Qt already offers a number of means related to Wayland and this will trend rather increase. Currently offered are QtCompositor APIs. There's hope to replace X11 for one more reason: Qt Quick 2’s OpenGL / OpenGL ES2-based windows manifest resize glitches on X11 window managers. It’s apparently not a problem on Macs however. I also can’t wait to see more custom compositors on various embedded devices.

Qt Mobility

Maintainer of Qt Mobility Alex Blasche informed that these APIs and implementation get important revitalization. This module was designed and implemented in Nokia times and missed reasonable investment after Qt went to Digia. Many Qt Mobility APIs are highly welcome on phones or tablets for improved code portability.

However, concerns were raised about its Contacts API. The question was, how often the detailed contacts data is used by apps, statistically and in practice. We have not matched Tizen's system contacts with the Mobility APIs yet, for now it's a nice-to-have task for adoption if you’re interested.

QtWebKit

Qt Quick is not just sufficient for implementing even most sophisticated UIs; we believe it is actually more practical and future-proof solution for mobile app development than over one hundred of HTML5/Javascript-based frameworks that are floating over the "web" and fragment it. Qt Quick apps do not need a web runtime to handle JavaScript code and APIs such as XMLHttpRequest that are exposed by some web sites or services. But to handle web elements exposed by some web sites it is still useful to have a HTML5-compliant web engine as an option.

So far in Qt 5, HTML5 runtime is delivered by an updated QtWebKit module exposed both to QtWidgets and Qt Quick 2. After departure of Google from the WebKit project and taking it over by Apple, it became clear that some replacement will be needed. Qt Project is not able to maintain v8 engine on its own separately from WebKit; actually nobody does this. The WebKit team in Digia is basically too small for such costly efforts.

Approaches to making a transition from QtWebKit to other web engine were quickly discussed. Qt would adapt the blink engine from the Chromium project. It is actually in development as QWebEngine, a thin layer around Chromium for QtWidgets and Qt Quick 2. This transition would take several steps. QtWebKit needs to be maintained for some time due to compatibility rules, especially that WebKit's API is broader than Chromium's API. Current WebKit's API could be deprecated in favor of Chromium. Then WebKit would be put in a "maintenance" mode, accepting only critical fixes.

Open Business Architecture

(Tuukka Turunen, director of Qt Commercial R&D at Digia)

This was very interesting session devoted to ideas for making Qt stronger by offering ready-made solutions in vertical space. Companies want to make money with Qt by selling goods such as modules, parts, and services. For example, when somebody wants to develop a medical solution, a ready-made and Qt-compatible component can be found for medicals.

Some form of a "marketplace" could be created for software components, services, and maybe also for job market around Qt. Companies that focus on Qt would benefit and make the ecosystem around developers stronger. It might be even complemented with end-user application store of some sort. Similar but not identical to Ruby gems, .NET accelerator, etc. And hopefully more open.

Nice to see Digia not only supports the idea but also popularizes it. If only 1% of the estimated (Digia, 2013) 500 thousands of Qt developers worldwide joined the organized Qt marketplace that would be already noticeable success...

On negative side, there can be a risk of fragmentation, eg. two competing implementations of the same cryptographic algorithm. As a conclusion, attendees agreed that the idea should be first stripped down to a manageable part.

We believe such an initiative could bring a stronger portfolio of Qt components to software platforms in general, and Tizen is not excluded of course.

Tizen 3.0 Open Governance Aspect

Observing all the exciting improvements that happen in Qt and contributing where possible we realize chances for the Tizen 3.0's Open Governance [PDF] to repeat success of the Qt Open Governance. It looks very promising so we seem to be on right path :)


Thanks to Tomasz Olszak for collecting some minutes.