Tizen @ QtCS 2013 (part 1)

A quick recap of the Qt Contributors Summit 2013 (QtCS) in the context of Tizen. It was second main Qt Project event for me aimed at contributors where the outcome of discussions and planning directly affects direction of Qt development. This way development of Qt itself isn’t happening behind closed doors but is a meritocratic, consensus-based process. (In addition to this summit, users of Qt have their Developer Days in Europe and the USA every fall with that many topics and this year first Starter Edition debuts specifically tailored for people new to Qt, managers, or returnees looking for a refresher on the basics, please consider attending!)

Looking back, I come from a desktop mindset with fair share of work in specialized or embedded UIs. After 15 years of using Qt for most of my software development needs I found my portfolio started to include some of "mobile development" too. This year it seems I am not unique in this. Importance of mobile in the Qt development ecosystem is well reflected by the number of sessions related to mobile: be it the Qt Quick 2 graphical stack or the QML language. Having that area secured, Qt Quick takes a whole round to also include support for modern desktop mouse-driven interfaces. In addition QtCS was co-organized with KDE Akademy where mobile-related topics were first-class too.


For better efficiency this time I came with Tomasz Olszak, proud implementer of most of the Qt for Tizen port. As planned we attended as many sessions as possible (there were four parallel tracks) and took part in discussions. We also gave overview of Qt for Tizen topics. Below you can read everything that was remotely interesting and noted by us.

I would need to attend both events to get more complete overview but unfortunately I was only able to make it to the QtCS (July 15 and 16). Akademy and QtCS shared the same Venue in Bilbao, Spain and I was able to meet numerous friends from KDE and chat a bit. Quite a few of them took active part in QtCS too. By no means this is a full list but probably like 25%. Please also note that many agreements on new features or changes in Qt may be only verbal so far. For more information you’ll need to wait for more articles and follow-ups that most likely appear on Planet Qt and Planet KDE.

Tizen Q&A

During the two days observed some attention towards Qt for Tizen. Questions and answers include:

• What’s up with actual devices? We do not have or give out any, our work is possible thanks to excellent testing and build system work done by our contributor and device hacker Leon Anavi. It’s possible we will work more with publicly available embedded boards since we’re equally open to work with Tizen IVI (or general embedded profiles).
  
  
• Can it be installed/tested on a Galaxy phone? Some hacks may be possible but we’ve not seen any results in the wild. We’ll go back to you as soon as device options are available.
  
  
• What to do if I want to start writing or porting apps? You can do that quite well with your desktop’s Qt Creator! Just make sure you installed Qt 5.1 or newer (it already contains all patches) and our special Tizen UI components. You can build binaries for the development Tizen devices using open tools pulled from the Tizen SDK. See the download page (source code only for now). Once you get access to real devices, you can fine-tune the software for them.
  
  
• So how you get the big names to support you? As you can read on the home page, Qt for Tizen is a purely community-driven initiative entirely based on private time and money.
  
  

Frameworks Sessions

We participated in a few sessions mainly about QML/QtQuick. There are new very interesting features in the works that would land in Qt 5.2 or later. Most of them show a clear benefit from Qt for Tizen for app developers.

Assets

Assets is a tool for making Qt Quick UIs more adaptive. For example notation like asset://main.qml automatically points to a platform-specific location where suitable version of main.qml resides. It is also easier means for deploying assets to proper locations as required by given platform.

File Selectors

Alan Alpert

Another gem from the department of Adaptive UI are file selectors. This needs more of explanation. Selectors differentiate import paths depending on various factors defined by developer, platform or at runtime.

These days good looking applications cannot use one set of controls+styles and that look and feel well on all platforms, so your application may need more or less styling, one for each platform. Selectors API let us to a point the import line to right folder containing the style:

import "+platform/style.qml"

The "+platform" bit is a notation of platform selector, to be replaced with names of certain style folders:

import "android/style.qml"
or import "bb10/style.qml"
or import "ios/style.qml"
or import "sailfish/style.qml"
or import "tizen/style.qml"
or import "ubuntu/style.qml", etc.

Just go to given folder and put the code that is platform-specific.

Great Beyond CC BY-NC-SA2

So it works a bit like macros with #ifdefs from C language here but in a more declarative way. Without file selectors you’d need to either have different import line and separate main.qml files since imports cannot be part of javascript. This example is the most telling for us since we put much of emphasis on platform-compliant styling, specifically for Tizen UI. For now I have to use javascript with conditions, settings variables, which is less readable and less performant.

Possible uses do not end here:

• Differentiated import based on form factor: import "+formfactor" can translate to one of those (defined by common standards that yet have to emerge):
  
  
  import "desktop"
  or import "tablet"
  or import "phone", etc.
  
  I am also assuming having the folder layout a bit standardized would improve readability of the source code.
  
  
• Differentiated import based on screen size: import "+screensize" can translate to actual screen size:
  
  
  import "800x600"
  or import "1024x768"
  or import "1280x800", etc.
  
  Note that the list of screen sizes can be application or platform-defined (declaratively) elsewhere. The same selection can be done to alter application’s look and feel depending on DPIs. If your graphics design is meant to be scalable depending on DPI ranges but e.g. have pre-rendered icons for certain DPIs, import "+dpi" becomes:
  
  
  import "200dpi"
  or import "320dpi", etc.
  
  The same can be applied to screen orientation, import "+orientation" becomes:
  
  
  import "landscape"
  or import "portrait".
  
  
• Multiple selections can be combined in various ways. The combination depends on platforms you target and what the differences in targets are handled by your design. One possible combination ignores platform styles and focuses on form factor, screen and orientation: import "+formfactor/+screensize/+orientation" which can translate to:
  
  
  import "phone/1280x800/landscape"
  or import "tablet/1920x1024/portrait", etc.
  
  There can be also selection based on platform: import "+platform/+formfactor/+screensize/+orientation" which can be translated to:
  
  
  import "tizen/phone/1280x720/landscape"
  or import "android/tablet/1920x1024/portrait", etc.
  
  During the discussions we noted that someone may want to even have code dependent on which Android UI is used, eg. Samsung Galaxy (TouchWiz) or Google Nexus. That gives deeper selection such as:
  
  
  import "android/galaxy/tablet/1920x1024/landscape"
  or import "android/nexus/phone/1280x720/portrait"
  
  
• User-defined selectors would be also possible what for me clearly replaces variables in the build system. One would sometimes use "+branding" to address differences of the UI depending on what brand or customer is targeted. Possibilities are endless here.
  
  
• Selectors are resolved at runtime. Some of them such as orientation are known at runtime and can change and so can the include path what for example can involve reloading the UI. For me, behaviour in this area is not yet finally defined.
  

I am glad to see the comeback of Selectors since at one point they were even proposed with a code patch by Alan Alpert but discussion stopped for a while. Alan is ex-Trolltech/Nokia hacker from Brisbane office, an origin of Qt Quick/QML, and now works for BlackBerry. He was especially active during the summit and it’s interesting to spend time on technical things with him.

In next part of the report I'll cover plans for new QML elements, reworked QML engine, mobile platforms-related sessions (including Tizen!), WebKit, business topics, and Tizen 3.0.

Session moderated by Lars Knoll