Charts with Cascades: Integration through jQuery

The following guest post comes from Alessandro Bellotti, BlackBerry Developer Elite.
In applications that manipulate and display a huge amount of data, it is very useful to integrate charts to provide a better user experience while showing that data to the user.

Currently in Cascades, the Qt class Graph can’t be used. Several solutions have been used, including the use of a background image with overlaying text written by using a Label {}, but this approach never led to optimal results.

Fortunately, thanks to the great flexibility of the BlackBerry 10 Native SDK and to Angelo Gallarello, a member of our BlackBerry Dev Group in Milan who has shown us a great JavaScript library called jQuery Sparklines, we can solve the problem of using graphs in a very simple, fast and effective way.

jQuery is very flexible and easy to use. It supports seven different chart types and all of them are easily customizable.

A very cool feature is the possibility to test the custom parameters in real time thanks to the dedicated box and very detailed documentation on customizing charts.

charts with cascades

The integration into a Cascades project is very easy: the first step is to create an HTML file with a simple text editor. In our case, we name it “grafico.html” and it looks like the following:

charts with cascades_code

Minified can be downloaded here:

Select all the text in the two links and paste between:

<script type=”text/javascript”>  e </script>

of the “grafico.html” file.

To display the graph, you just need to add a WebView to your project (in the QML file that should display the graph), setting its URL to the location of your HTML file.

WebView {
     id: idWebView
     objectName: "idWebView"
     url: "local:///assets/webview/grafico.html"
     verticalAlignment: VerticalAlignment.Fill
     horizontalAlignment: HorizontalAlignment.Fill
}

The next step is to create the string with the values ​​that will be inserted in the grafico.html file to produce the graph.

In our case, I took a SQLLite database, and while rushing records with a Select, I created the string using the method of creating a function callable from the QML in the header file (HPP):

Q_INVOKABLE void readData (QString search);

and a Q_SIGNALS

void gotSparky(QString Sparky);

In CPP, I scrolled the database and for each record found and built the string in the global variable Sparky, maintaining the structure required by the jQuery library.

Finally, after reading all the records, I finished the creation by integrating the Sparky string with Sparky_Full which also contains the parameters for the creation of the chart. So I have set the string in QML “emit gotSparky(Sparky_Full);

void ApplicationUI::readData(QString search)
{
      QSqlDatabase database = QSqlDatabase::database();
      SqlDataAccess *sqlda = new SqlDataAccess(database.databaseName());
      QString appo = search;
      QVariant result = sqlda->execute(appo);
      Sparky_Full = "";
      Sparky = "[";
    if (!sqlda->hasError()) {
        int recordsRead = 0;
        if( !result.isNull() ) {
            QVariantList list = result.value<QVariantList>();
            recordsRead = list.size();
            for(int i = 0; i < recordsRead; i++) {
                QVariantMap map = list.at(i).value<QVariantMap>();
                if (i == 0){
                  Sparky = Sparky +  map.value("quantita").toString();
                }
                else {
                  Sparky = Sparky + "," + map.value("quantita").toString();
                }
            }
            Sparky = Sparky + "]";
Sparky_Full = QString("$('.sparkline').sparkline(")+ Sparky + QString(",{type: 'line', chartRangeMin: '0', fillColor: false, width: '720', height: '250'});");
            emit gotSparky(Sparky_Full);
        }
        if (recordsRead == 0) {
        //  showToast("NO Data!");
        }
    } else {
        alert(tr("Read records failed: %1").arg(sqlda->error().errorMessage()));
    }
}

In the QML file you just need to add a few lines of code. I created two “property” that have the task of checking if the app is already connected to the “onGotSparky” signal (because in that case the data is duplicated), and a support string for the output string coming from the C++ function.

import bb.cascades 1.0
import bb.system 1.0
 
Page {
    property variant connessoSparky:0
    property string sparky_String: ""
 
onCreationCompleted: 
        if (connessoSparky == 0){
            _app.gotSparky.connect(onGotSparky)
            connessoSparky = 1 
        }
            _app.readData(“SELECT * FROM myDataBase”)
    }
 
function onGotSparky(stringa) {
        sparky_String = stringa
}

I put in the evaluateJavaScript() in a ActionItem to keep everything separate. In practice, when onTriggered:{} is issued, the string is passed to the HTML page that elaborates it and gives the graph.

    actions: [
        ActionItem {
            id: actGraph
            title: "Titolo"
            imageSource: "asset:///images/menuicons/ic_chart.png"
            ActionBar.placement: ActionBarPlacement.OnBar
onTriggered: {
                                 waterWebView.evaluateJavaScript(sparky_String)
            }
        }
   ]

That’s all! Let us know if you have any questions in the comments below, and happy coding!


Squish GUI Tester 5.1 Released

As announced today on www.froglogic.com, we are excited to make available Squish 5.1.

A lot of new features found its way into this release. This includes Multi-touch gesture support, an interactive “object not found” debugging wizard, new integrations for Bamboo, JIRA, TeamCity and the Robot Framework, full-blown Google Chrome support, added support for Qt 5.2, and Java 8, improved support for testing Qt and QML on QNX, Android and VxWorks, major improvements in the Python editor and more.

You can read the full press release and release notes at http://www.froglogic.com/news-events/index.php?id=squish-5.1-released.html.

We are excited to finally share this new version and look forward to your feedback!

Qt 5.2 Over 1 Million Downloads


Congrats everyone! Since its release in December 2013, Qt 5.2 has been downloaded over 1 million times. That is pretty darn awesome with about 10K downloads ticking in daily. Nice! Thanks to all for your support in spreading the Qt love. Let’s keep it kicking. Qt 5.3 is just around the corner where we hope to convert even more devs to the Qt world.

This figure really shows Qt as a key player in the software development world with a strong community behind it. The opportunity with Qt for hobby developers and large enterprise projects is evident via our fast-growing ecosystem. Qt’s use in 70+ industries and the large amount of market-leading Qt-powered applications and devices has an even larger potential for monetization and other new opportunities for all of us. Thanks again for the support and keep the conversation going with us. Let us  know what we can do better or more of to spread the use of Qt everywhere.

We welcome your feedback!

P.S. Remember to take the 2014 7th Edition Developer Economics Survey and stand up for Qt (and maybe win some nice prizes while you are at it): http://www.vmob.me/DE3Q14Digia

And, if you are really into taking surveys, help Qt move up the ranks in the Research2Guidance Cross-Platform Tools survey: http://research2guidance.com/cross-platform-tool-benchmarking-2014-take-part-and-get-your-valuable-reward-right-after-the-survey/

/KB

Qt Weekly #6: Sorting and filtering a TableView


The QtQuick Controls TableView offers a variety of ways to provide data. Supported data model types include the traditional QAbstractItemModel derivative models, QObjectList, JS arrays, and even plain numbers. This flexibility imposes an unfortunate limitation that TableView doesn’t know how to sort arbitrary data models. TableView merely offers a visual enabler, a sort indicator, and the actual sorting is left to the application. In this blog post, we’ll present an example of sorting and filtering a TableView.

An example for sorting and filtering a TableView

The example is based on a QSortFilterProxyModel derivative model. The source model can be any QAbstractItemModel subclass, but the proxy model has been specifically tweaked to be used with QML data models such as ListModel and XmlListModel. The example uses an XmlListModel that loads images from Flickr.

TableView {
    id: tableView

    sortIndicatorVisible: true

    model: SortFilterProxyModel {
        id: proxyModel
        source: sourceModel.count > 0 ? sourceModel : null

        sortOrder: tableView.sortIndicatorOrder
        sortCaseSensitivity: Qt.CaseInsensitive
        sortRole: sourceModel.count > 0 ?
                  tableView.getColumn(tableView.sortIndicatorColumn).role : ""

        filterString: "*" + searchBox.text + "*"
        filterSyntax: SortFilterProxyModel.Wildcard
        filterCaseSensitivity: Qt.CaseInsensitive
    }
}

The above code snippet presents the most relevant parts of the attached example. In order to enable sorting and filtering, it makes the sort indicator visible and sets up property bindings to the appropriate UI elements, and SortFilterProxyModel handles the rest.

Full source code for the example: tablesortfilter.zip.

Qt Weekly is a new blog post series that aims to give your daily Qt usage a boost. Stay tuned for next week’s post!

Qt on Android: The top 5 markets

The power of Qt running on the ubiquity of Android is a potent combination that can be used to great effect in a number of different applications. But are there certain apps that really shine when they’re built using this dynamic duo?

Before I go any further, let me introduce myself. My name is Andy Gryc, and I’ve worked in the embedded industry for my entire career. I’ll be contributing a few guest blogs in anticipation of KDAB’s Qt on Android webinar, presented by BogDan Vatra with a little assistance from yours truly. I won’t be delving into the bits and bytes—I’ll leave that to BogDan as the world’s foremost “Qt on Android” expert. Instead, I want to ask some meta-questions.

My first question is obviously this: What types of apps rock Qt on Android?

  • Medical – Real-time and reliable access/control of hardware (pure Qt embedded system with an amazing UI)
  • Home Media – A set-top box that can leverage a standard development platform (Android) but allows precise control of the embedded hardware decoders/encoders (Qt/C++)
  • Enterprise – Server/cloud applications that can be deployed on Windows, Mac, or Linux desktops (Qt) as easily as on phones (Qt + Android)
  • Automotive – Easy access to low-level vehicle systems (C++) and high performance user interfaces (Qt) with an app framework (Android) for infotainment systems
  • Gaming – Games written using a powerful C++ and graphical toolkit (Qt) that can be ported to multiple desktop, console, or mobile platforms (including Android)

Although these are my top five, there are certainly others. In fact, there is great potential for Qt on Android wherever a system has either of these two characteristics:

  • Any app that needs low-level access from a high-level common environment—much like in-dash apps for the automotive market. For example, airline in-flight entertainment, heavy machinery, or white goods (sophisticated appliances)
  • Anything that needs cross-platform deployment strategies between mobile and non-mobile (desktop or embedded)—like the enterprise market. Other apps that fit into this category are satellite radio receivers, universal remotes, network admin consoles, even educational/academic applications

I’m sure there are other industries and apps that I haven’t thought of. I’d love to hear if you are using Qt on Android for a different purpose or can think of other ideal applications.

Looking for more detail? Join BogDan and me on May 6 for “Qt on Android: Is it right for you?” We’ll be providing an overview of this technology marriage, and how you might be able to apply it to your project.

Want even more? In the month of June, BogDan will be extending his European Coffee and Code tour to several cities across the US. This will be a hands-on technical session: getting your development ramped up quickly, explaining how Qt and Android works, and for the really adventurous, getting into the nuts and bolts like JNI interfaces and Qt-to-Android surface control.

The post Qt on Android: The top 5 markets appeared first on KDAB.

Update for Qt Enterprise Embedded


It’s time for an update on Qt Enterprise Embedded – featuring Qt Creator 3.1.0, integrating new Qt Enterprise modules, connectivity improvements and a few other items we hope you will like. For Qt Enterprise Embedded, we are providing regular patch updates with bug fixes, enhancements and pre-built versions of our latest Qt Enterprise components.

Here is an overview of what we have done since last time:

Cloud-Connect Your Device

As cloud-connectivity is part of modern embedded device creation, we’ve made it even easier to integrate into Qt Cloud Services. Access to Enginio Data Storage is now provided built-in with the Qt Enterprise Embedded. Through Qt Cloud Services, you can immediately instantiate a whole cloud backend for you embedded, mobile and desktop Qt clients–all through a convenient Qt API. Together with the newly added Bluetooth support (using BlueZ) and the existing Wi-Fi and wired network support, you have everything you need for implementing Internet-of-Things, all within the reach of single technology.

Qt Data Visualization library

For 3D visualization of data we’ve integrated the Qt Data Visualization library to the built-in offering. With the library you can create amazing and well-performing 3D visualizations using 3D bars, 3D scatters and 3D surfaces.

Qt Quick Enterprise Controls (version 1.1)


With Qt Enterprise Embedded we provide a complete set of Qt Quick UI controls to give you a head-start in modern UI development. Both basic Qt Quick Controls as well as the industry-specific Qt Quick Enterprise Controls are built-in to the software stack as well as the UI designer in the development environment. Qt Quick Enterprise Controls is a continuous project where we’ve implemented and provide support for more complex, industrial UI components that are requested by our customers. This release adds a couple of more controls in addition to previous ones and should you have ideas for new ones, let us know!

QSerialPort

We are fortunate to live in a world with USB, Wi-Fi, Bluetooth etc, but sometimes it’s useful to be able to connect some copper wires to the serial port. The QSerialPort API allows you to access both physical and virtual serial ports using a convenient cross-platform API as well as use the Qt streaming classes to read/write data to the port.

Other improvements:

In this release we introduce the possibility for incremental deployment to devices. This reduces the time it takes to deploy your software to your device.

Previous versions of Qt Enterprise Embedded offered USB-connection to the device as the primary way to deploy, run and debug on devices. In addition to USB we are now supporting also connecting to devices in your local network using IP. This should ease sharing of devices among team members, setting up devices for automated testing etc.

We have also updated the OpenSSL library with a fix for the Heartbleed Bug vulnerability.

In addition we have made quite a few updates to our documentation.

We have also put a lot of effort into fixing issues that our users have encountered so far. Further information can be found on the change log.

Reference Devices:

Our reference devices are ones we have set up to run out-of-the-box with Qt Enterprise Embedded, great for evaluating and prototypic. Qt Enterprise Embedded is not limited to these devices, and we are happy to help you up and running on other devices. In fact, for the Embedded Linux based software stack, we provide many more recipes directly for the Yocto Project’s tooling for you to customize your own stack for production.

Device OS
Google Nexus 7 (2012 version) – 1.2 GHz Quad-Core ARM Cortex A9, Tegra 3 GPU, 1GB RAM Android 4.2
BeagleBone Black – 1GHz ARM Cortex A8, PowerVR SGX530 GPU, 512MB RAM Android 4.2 & Linux
BeagleBoard xM – 1GHz ARM Cortex A8, PowerVR SGX530 GPU, 512MB RAM Linux
Boundary Devices SABRE Lite (Freescale i.MX 6) – 1 GHz Quad-Core ARM Cortex A9, Vivante GC2000 GPU, 1GB RAM Android 4.2 & Linux
Raspberry Pi model B – 700 MHz ARM1176JZF-S core, Broadcom VideoCore IV GPU, 512 MB RAM Linux
Emulator Android 4.2 & Linux

 

Getting Started

Request a Free 30-day trial via the Try Now page to get started with Qt Enterprise Embedded.

We are looking forward to your feedback!

Qt Creator 3.1.0 released


We are happy to announce the release of Qt Creator 3.1.0! This release of Qt Creator is packed with bug fixes and improvements, not to forget some new experimental features.

We finally integrated a Clang-based C/C++ code model as an option for code completion and semantic highlighting. It is experimental so far, so you need to enable the plugin in Help > About Plugins > C++ > ClangCodeModel, restart Qt Creator, and tell it to actually use it in Options > C++ > Code Model. We are interested in your feedback on how well it works. Please report issues on our bug tracker or get in contact with us on the mailing list or irc.

iOS support has moved out of experimental state, and fully supports QML debugging and profiling now. Also, several issues with debugging have been fixed, and many little things were tweaked (for example, you can now set the simulated device in the simulator run configuration).

In exchange we added a new experimental plugin for another platform: WinRT. You can read more about it in its own blog post here.

An important note is, that we drop support for debugging with versions of GDB that do not have a Python interface. This includes the version of GDB that is shipped with older versions of Xcode on Mac OS X. The good news there is, that we put a lot of effort into making debugging with LLDB a great experience in Qt Creator, so you should just use LLDB instead :)

Also notable is the experimental Beautifier plugin, which allows you to apply different external source code formatters on your files. It currently has support for Artistic Style, Clang-format and Uncrustify. Many thanks to Lorenz Haas for contributing this!

Additionally, Android support has received many tweaks again, including some minimal support for editing Java files with highlighting, indentation and keyword completion. You can now manage debug tokens and runtime configurations for QNX from Qt Creator, and debugging on QNX now supports more pretty printers as well. The QML Profiler and Qt Quick Designer have received many fixes, the Qt Quick Application templates have been simplified, support for qrc has been polished (for example, qrc files now appear as nodes in the project tree), and much much more. You find a more thorough overview in our change log.

Qt Creator 3.1.0 is part of the Qt Enterprise Embedded update today, and it will appear as an update in your Qt online installer (this may take a bit while it is rolled out to the mirrors). The Qt Creator open source standalone packages are also available on the Qt Project download page, and Enterprise Customers find them in the Qt Account Portal.

Qt Weekly #5: Widgets on a QHeaderView


Just recently someone had asked about having QComboBoxes placed over the sections inside a QHeaderView, initially I thought this would be fairly straightforward as you could use the setViewportMargins() and put the widgets at the top.  But unfortunately this is not possible to do because the itemviews set the viewport margins itself and setting it outside of this will cause problems so that approach is not recommended.

Therefore the way to get it working is to actually create the widgets and place them on the QHeaderView directly, this means that we have to adjust them manually when sections are resized, moved or when the itemview itself is scrolled.  So in order to do this we need to start off by subclassing QHeaderView.  In this case I am focusing purely on a horizontal header as this makes it more straight forward to focus on instead of trying to account for the direction sections are moving.

MyHorizontalHeader(QWidget *parent = 0) : QHeaderView(Qt::Horizontal, parent)
{
     connect(this, SIGNAL(sectionResized(int, int, int)), this, 
             SLOT(handleSectionResized(int)));
     connect(this, SIGNAL(sectionMoved(int, int, int)), this, 
             SLOT(handleSectionMoved(int, int, int)));
     setMovable(true);
}

We have added two slots already here, one is for handling when a section is resized and one for when a section is moved.  We will get to them in a bit, but first we will cover the initialization of the widgets.  We cannot do this in the constructor (although we could do if we know more about the itemview it will be associated with, but for this case I want to be as generic as possible) as we don’t know how many sections there will be.  So the best place to do this in a reimplemented showEvent():

void showEvent(QShowEvent *e)
{
    for (int i=0;i<count();i++) {
       if (!boxes[i]) {
          QComboBox *box = new QComboBox(this);
          boxes[i] = box;
       }
       boxes[i]->setGeometry(sectionViewportPosition(i), 0, 
                                sectionSize(i) - 5, height());
       boxes[i]->show();
    }
    QHeaderView::showEvent(e);
 }

The boxes array is just a QMap<int, QComboBox *> with the integer referring to the logical index of the section the combobox is connected to.  In order to get the correct position on the viewport for the section we use sectionViewportPosition() and sectionSize() is used to get the size of the section.  The reason the -5 is there is purely so that I can see a bit of the section underneath to allow moving of the sections.  If you only want to see the splitter to resize the sections you can change it to -2.

What is left then is to react to the resize of the sections and the moving of the sections with the following slots:

void handleSectionResized(int i)
{
    for (int j=visualIndex(i);j<count();j++) {
        int logical = logicalIndex(j);
        boxes[logical]->setGeometry(sectionViewportPosition(logical), 0, 
                                       sectionSize(logical) - 5, height());
    }
}
void handleSectionMoved(int logical, int oldVisualIndex, int newVisualIndex)
{
    for (int i=qMin(oldVisualIndex, newVisualIndex);i<count();i++){
        int logical = logicalIndex(i);
        boxes[logical]->setGeometry(sectionViewportPosition(logical), 0, 
                                       sectionSize(logical) - 5, height());
    }
}

The code is fundamentally the same in both slots but the loop is tweaked to limit how many widgets have to be touched, when a section is resized we only go from the visual index of the one resized throughout the rest of the sections after that.  When a section is moved we need to go from where the first visual index is hit to the end of the headerview as the other sections will have to be updated to adjust.

So far so good, the only thing left for us to do now is handle the case where the itemview is scrolled as we need to reposition the widgets again.  Since the QHeaderView is not being notified in any way that this occurs as it is on the viewport we need to connect this up from the itemview itself when a scroll occurs.  To do this we need to reimplement scrollContentsBy():

void scrollContentsBy(int dx, int dy)
{
   QTableWidget::scrollContentsBy(dx, dy);
   if (dx != 0)
      horizHeader->fixComboPositions();
}

What is not shown here is the constructor which creates an instance of the MyHorizontalHeader class and sets it with setHorizontalHeader().  So whenever the contents are scrolled in either horizontal direction we call fixComboPositions() which does:

void fixComboPositions()
{
    for (int i=0;i<count();i++)
        boxes[i]->setGeometry(sectionViewportPosition(i), 0, 
                                 sectionSize(i) - 5, height());
}

In effect that is the same as what showEvent() does, since we don’t know how much was made visible or hidden the easiest way is to just go over all the widgets.

And there you have it, a fairly straightforward approach to getting widgets on a QHeaderView on a per section basis which should be easily adaptable for your own needs.

Qt Weekly is a new blog post series that aims to give your daily Qt usage a boost. Stay tuned for next week’s post!

Heartbleed Bug (CVE-2014-0160) and Qt


Although Qt as such is not affected by the Heartbleed Bug (CVE-2014-0160) found in OpenSSL, it affects users of Qt, so I wanted to write a short summary about the topic.

As defined at http://heartbleed.com:

“The Heartbleed Bug is a serious vulnerability in the popular OpenSSL cryptographic software library. This weakness allows stealing the information protected, under normal conditions, by the SSL/TLS encryption used to secure the Internet. SSL/TLS provides communication security and privacy over the Internet for applications such as web, email, instant messaging (IM) and some virtual private networks (VPNs).

The Heartbleed bug allows anyone on the Internet to read the memory of the systems protected by the vulnerable versions of the OpenSSL software. This compromises the secret keys used to identify the service providers and to encrypt the traffic, the names and passwords of the users and the actual content. This allows attackers to eavesdrop on communications, steal data directly from the services and users and to impersonate services and users.”

Qt as such does not include OpenSSL, but when OpenSSL is installed in the system Qt applications can use it. Thus, depending on what OpenSSL version you have in the system, your Qt based application may be affected by this vulnerability if you use OpenSSL functionality. OpenSSL versions 1.0.1 older than 1.0.1g are vulnerable. Also OpenSSL versions older than 1.0.1 are recommended to be updated to 1.0.1g, although they are not subject to this vulnerability. The fix for OpenSSL is already available, and all users of vulnerable OpenSSL versions should migrate to OpenSSL version 1.0.1g or recompile OpenSSL with -DOPENSSL_NO_HEARTBEATS.

The servers of Qt Project and Digia are all updated and not affected by the vulnerability any more. Those servers that may have been affected by the vulnerability are now throughly checked and certificates will be changed. Also all Qt Cloud Services have been updated to latest OpenSSL. Similarly as all Qt users leveraging OpenSSL, the users of Qt Cloud Services client library should check that they use the fixed OpenSSL version in their applications. We will send dedicated email communications to users of Qt Cloud Services about this.

We have now gone through in detail all of our around 30 Qt related services that use SSL/TLS functionality. It is always good practise to regularly change your passwords, but there is no need to do so in the Qt servers due to the Heartbleed Bug. For example Qt Account, Bugreports, qt.digia.com, qt-project.org and Codereview were never vulnerable by the Heartbleed Bug. We will revoke and change certificates as a security precaution. Some of these are already done and some are in progress.

There is also a minor risk for vulnerability via the Qt Enterprise and Qt Mobile online installers, which use https communications. Unfortunately some of the Qt online installers and the distribution servers used for Open-source downloads are affected by the Heartbleed Bug vulnerability. We are in progress of updating the installer framework and creating new installers, which are estimated to be available during next week.

We have also notified users of Qt Enterprise Embedded about the vulnerability and instructions to avoid it. Next release of the Qt Enterprise Embedded reference stack contains the fixed version of OpenSSL.

If you have any questions, please do not hesitate to contact Qt Enterprise support via your Qt Account or Qt Project security mailing list.

 

ownCloud Client 1.6: The Tour

Now that ownCloud 1.6.0 beta1 is out, it’s time to explain the story behind it:

owncloud-icon-256This release was developed under the promise that it would improve performance 1), and we have made tremendous improvements: Using a new Qt-based propagator implementation, we can now perform multiple simultaneous up- and downloads. We still provide the old propagator for certain situation where it’s more suitable, such as for situations where bandwidth limitation is needed.

Furthermore, the sync journal access code has been significantly optimized. It paid tribute to most of the high CPU load during the mandatory interval checks. CPU usage should be much lower now, and the client should be usable with more files at the same time.

Windows users should also find update times improved as the time spent in file stat operations has been reduced. Mac OS X users will enjoy the benefits of a much improved file watcher. To be able to use the more efficient API, 1.6 drops support for Mac OS Snow Leopard (10.6) and now requires Mac OS 10.7 or better.

At the same time, production releases are now using Qt 5 rather than Qt 4 on Windows and Mac OS X2). This fixes a lot of visual bugs in Mac OS X, especially for Mavericks users, and allows us to profit from improvements in the SSL handling, especially on the Mac.

We also implemented an item that was on many peoples wish list: a concise sync log. Next to the database, the sync folder now holds a hidden file called .owncloudsync.log. It will store all sync processes in a minimal CSV file. Contrary to previous logging facilities, it always logs and only collects information relevant to the actual sync algorithm decisions.

Because this tour was not as colorful as the previous one, let’s close this blog post with a feature contributed by Denis Dzyubenko: The settings dialog on Mac OS X now has a native look & feel:

Watch on Youtube

Get ownCloud Client 1.6.0 beta1 now and provide feedback!

1) Now that while the client is multi-threaded, you may find that the transfer time still doesn’t improve as much as you would expect. This is due locking issues on the server which prevent efficient parallel transfers. This has been improved in 1.7, and could potentilly improved even further by implementing support for X-Sendfile/X-Accel-Redirect in SabreDAV, the DAV framework used by ownCloud server.

2) We can’t do the switch even on modern Linux distributions mostly due of the poor support for modern and divergent Systray/Notification area support in Qt5: Even in Qt 4 we could only use it because Canonical had patched their Qt to make QSystemTrayIcon work with Unity, which they have not ported to Qt 5 yet. Gnome 3 also hides away traditional Systray icons way to well, not to speak of Plasma. Any leads would be helpful.

PS: Martin’s blog on the subject indicates that Qt 5.3 might solve the problem.

Qt Quick Enterprise Controls 1.1 Released


Today we have released version 1.1 of the Qt Quick Enterprise Controls add-on that was first released in January. The Qt Quick Enterprise Controls library provides a collection of Qt Quick-based controls that can be customized and easily extended to match the desired look-and-feel of the user interface. Together with the Qt Quick Controls library, it forms a full set of controls for Qt Enterprise and Qt Mobile customers to leverage in their applications.

The focus of this release has been on improving the existing controls, with some new features added:

  • The tickmark functionality behind the CircularGauge was abstracted out, allowing Dial to also benefit. This opens up Dial to new possibilities; for example, it is now possible to combine the stepSize property with tickmarks and labels to create a “switch” that snaps to certain options.
  • PieMenu got several improvements:
    • It will now stay within the bounds of the window when opened, ensuring that all options are visible at all times.
    • Icons will be scaled if their size exceeds the radius or circumference of the section they are in.
    • The title property was added. This property controls the text that is displayed above the menu when there is no currently selected menu item.

A new version is always nicer with new controls, so we would like to introduce StatusIndicator. This control emulates a typical LED indicator found on electrical equipment to visualize on/off state. As with all of the controls, it uses generated graphics to ensure scalability across all target devices. It also provides a color property to provide extra context amongst other indicators.

Qt Quick Enterprise Controls are included in the Qt Enterprise and Qt Mobile Licenses, so they are free for our licensees to use and are fully covered by our standard support. You can test out the Qt Quick Enterprise Controls and the rest of Qt Enterprise or Qt Mobile by downloading our free 30-day evaluation. Qt Enterprise and Qt Mobile customers can download Qt Quick Enterprise Controls binaries and source code through the online installer. The module can be found under Qt Enterprise Add-Ons in the package manager. Source packages are also available in Qt Account Downloads. For further information about the controls, please visit the documentation.

This add-on is developed for our customers based on their input, to provide more complex, industry-specific UI controls, and we are happy to hear your suggestions about what should be included. If you have any issues using them or want to share ideas for further development, just contact our support team through the Qt Account Support Center.

Qt on Android Episode 4

erratum 2014-04-13: Updated Bundle Qt libs pros and cons.

Update2: Here you can read also the Chinese version, thanks goes to

After we’ve learned how to set up the development environment and how to use Qt on Android, it’s time to move forward and in this article we are going to learn about different deployment systems and how to sign the package in order to publish it in any Android markets.

Choosing the right deploying system

Qt Creator supports three deployment systems:

  • Use Ministro service to install Qt
  • Bundle Qt libs in APK
  • Deploy local Qt libs to temporary directory

Android_Qt_Creator_deployment

Use Ministro service to install Qt

Back in 2009, when I started this project, there were only a few devices out there with Android. Most of them had very limited free space (less than 100 Mb), so, using Qt statically or bundling Qt libs into the APK was out of the question, also back then Google Market had way more limited size than today (50Mb limit/apk). As you can see I was forced to invent Ministro.
Even today most of the mid/low-end devices don’t have too much space!

How it works?

  • Instead of bundling everything into your APK, your package will contain ONLY your application .so file(s), its needed resources and a list with all needed external libs.
  • When your application starts, it tries to connect to Ministro service, if it fails it means that Ministro is not installed and it opens the Android Play for the user to install Ministro. After it successfully connects to Ministro, it sends the dependencies list.
  • Ministro checks if these dependencies are already available, if not, then it downloads only the missing ones in a central secure location and it sends back to the application another list with all the needed libs that the application must load before it loads your qt application.
  • The application loads the libs from Ministro’s location, then your application, then it continues the running process.

Now let’s see the advantages and disadvantages of using Ministro.

Advantages:

  • Using Ministro, the user needs to download the Qt libs ONLY once. If the user downloads another Qt application, it will use the existing libraries. Of course if that application needs more libs, Ministro will download only those that are missing.
  • Ministro can detect if the device armv5 CPU has VFP or if the device armv7 CPU has NEON and it can download libs specific to that device CPU. Even if your application is not built with these CPU features, just using Qt libs built with them will make it run faster (on armv5, VFP really makes the difference, it will be way much faster). Currently these libs are not available, but I intend to publish them starting with 5.4.
  • Ministro can upgrade Qt libs, without you needing to release a new application.
  • You can target all Android platforms with a single APK. Because most likely your application (.so) file(s) are not very big, they can easily fit into a single APK. If your application doesn’t do intensive computation you can use only armv5 .so files to target both armv5 and armv7 platforms, because even if your APK contains only armv5 libs, Ministro will download the Qt libs specific for your device.
  • You can use your own Ministro sources with your own libraries. Basically you’ll need an HTTP/HTTPS server with a valid certificate and to create and upload Ministro’s repository to that server. Because there is a lot to tell on this topic, I’m going to create a wiki page with all the information you need about this topic.

Disadvantages:

  • Some people don’t like Ministro because the users must install Ministro service once. There are lots of apps out there which require other services, if my mother can install and use Google Hangouts on an older Android version, which needs Google Play service to be installed manually, or MX Player that needs MX Player Codecs to be installed manually, I’m pretty sure she will be just fine with any Qt application which requires Ministro to be installed once.
  • Ministro upgrades Qt libraries and it might break things. I’m very concerned on this topic! To address this problem Ministro uses a different location for every major Qt release e.g:

    Even more, every source is using a Debian-like release scheme with three different repositories:

    • unstable – this is a pre-release repository used by Qt Project/Necessitas developers to test a new release. Before a new SDK release is announced, this repository is used to push the new libs and test it before officially announcing it.
    • testing – after all tests pass, the libs are moved from unstable to testing repository and then we announce them on https://groups.google.com/forum/#!forum/android-qt, http://lists.qt-project.org/pipermail/android-development and on http://mail.kde.org/pipermail/necessitas-devel. The new version will stay in testing repository for at least one month to give enough time for the developers to test their existing apps using the new libs. Additional updates will be released in testing repository and the period may be extended if any regressions are reported. A new update must stay at least two weeks in testing repository.
    • stable – after testing repository is regression free, the libs are moved to stable repository. It is very important that testing repository is regressions free before it lands on stable because in ~7 days all Android Ministro users will be notified about the new release and it will be very unpleasant if the users apps do not run any more!

Using this scheme Ministro users have no regression in 4 years and 13 Necessitas releases and 5 Qt project releases!

As you can see Ministro is quite safe on this matter!

Bundle Qt libs in APK

This feature was added recently to Qt Creator. Beside your application and your resources, Qt Creator adds all Qt libraries that your application needs to run.

Advantages:

  • The APK contains everything it needs to run.
  • erratum 2014-04-13: The ability of including custom builds of Qt. Improves time-to-market as you don’t have to wait for official releases before you can get your crucial bug fix. There’s also no waiting period after a new version of Qt is released before you can deploy it with your application.
  • erratum 2014-04-13: The Qt libraries are not updated behind your back, no worries about sudden regressions.
  • erratum 2014-04-13: The libraries will be served with your package in the store’s main infrastructure, whereas the Ministro libraries are served in the Qt Project infrastructure. The latter has not been tested for very large download volumes, so at this point we do not know how well it can serve a hugely successful application.
  • erratum 2014-04-13: If done through Google Play, the download goes through the regular mechanisms on the device, so it continues in the background when your user suspends it, with progress indication in the status bar, and it obeys your users’ settings regarding downloads and updates over a mobile data connection.

Disadvantages:

  • The APK is HUGE due to Qt libs which are pretty big (+40Mb/platform). erratum 2014-04-13: The APK is big comparing with the Ministro’s version, due to Qt files which are pretty big. Qt files can go slightly over 40Mb/platform if you are going to use all of Qt modules. Of course your application doesnt need all the modules, so, if your application uses only Qt Quick Controls + Qt SVG + Qt Multimedia + Qt Sensors + Qt XML modules, Qt files (libs + plugins + additional files) are ~20Mb/platform and your APK will be ~10Mb.
  • All Qt libs must be unpacked! So your application will need a lot of free space to run (+50Mb) erratum 2014-04-13: The APK is NOT deleted after you install the application, but is kept by Android O.S. in order to access its assets, so, don’t forget to to count its size as well. At first run, our application will extract Qt libs and plugin to the application home folder. To check exactly how much space your application uses, you have to go to Settings->Apps->your application, and check Total of the STORAGE section. I checked gallery Qt Quick Controls example with Qt SVG + Qt Multimedia + Qt Sensors + Qt XML and it occupies slightly over 35Mb. Currently only just a very few apps on Google Play require that much space to run.
  • Most of the mid/low-end device users can’t afford to spend that much free space!
  • Due to big size you can’t target more than one platform/apk. You must create an APK for every platform (armv5, armv7, x86). This will be confusing for armv7 users because AFAIK Google Play will list your application twice, once for armv7 and once for armv5 (see MX Player Codecs). If my mother can install a simple application, I’m pretty sure that she doesn’t know what kind of CPU her phone has, actually I’m pretty sure that she doesn’t know what a CPU is or if her device has such a thing … erratum 2014-04-13: it seems that Google Play doesn’t list your application twice.
  • Can’t use VFP on armv5 devices and NEON on armv7 devices.
  • Qt libs can’t be shared by multiple Qt apps on the same device.
  • Can’t get Qt libs updates automatically.

As you can see there is no perfect solution, the pros from Ministro go to cons of the Bundle Qt libs in APK and the cons go to pros :).

Deploy local Qt libs to temporary directory

This deploy system is used mostly by Qt hackers when hacking on Qt itself because it is the fastest way to deploy modified Qt libs on the device to test them. Do not use it in production!

In the end you are the one who will make the choice, I just wanted to present you all the advantages and disadvantages of every deployment system.

Package Signing

This is the last and most important step before publishing. In order to sign the package you’ll need a keystore and a self-signed certificate.

If you don’t have such a certificate, Qt Creator can help you to easily create one, you just need to press create button and fill the keystore and certificate fields, check the following image:

QTC_CreateCertificate

You can only upgrade your application with the same certificate you publish it with! So, make sure you are making backups of the keystore file.

If you already have a keystore, then just browse its location.

Next step is to switch your project to release and check sign package and open package location after build, check the following image:

QTC_SignPackage

After you’ve pressed run button, in a few moments Qt Creator will open the location where your package was built and signed, be sure you are choosing the signed one (QtApp-release.apk)! Check the following image:

QTC_SignOutput

That’s all folks, see you next time when will see how to use JNI to extend our Android applications.

The post Qt on Android Episode 4 appeared first on KDAB.

Stand Up for Qt | Vision Mobile 7th Developer Economics Survey


VisionMobile Developer Economics Qt

Help us push the Qt name and technology. If you love Qt, take the 7th Vision Mobile Developer Economics survey, and stand up for Qt!

The Vision Mobile Developer Economics survey is the largest, most global research series on the app economy and developer trends. Take the latest survey and speak your mind on the latest developer trends – How are challenger platforms moving up? Is HTML5 in decline? Is Qt usage increasing?  What language do most devs use? What are the trending tools of the trade?

Please take 10 minutes of your time  and win some great prizes while you’re at it! The results of this survey will become available as a free PDF report in July 2014.

Each of the respondents gets a free 1-month subscription of crash reporting for their apps (value of 19 USD, courtesy of Bugsense) – as well as a 20% discount to continue using the service after the 1 month is up. Just take the survey and Bugsense will be in touch to set up your prize.

There are also some great devices up for grabs – the winners will be determined in a draw, which Vision Mobile will hold after the survey closes (mid May 2014).

  1. One iPhone 5s
  2. One Samsung Galaxy S5
  3. One Lumia 930 (courtesy of Nokia)
  4. One BlackBerry Z30

Let’s join forces and support Qt! Learn more about the survey and help us the spread the word via the Qt community.

Thanks for the support!

 

Qt Cloud Services Introduces Real-Time Communication


I’m happy to announce a major upgrade of Qt Cloud Services. The upgrade expands the services to live experiences by introducing a new Managed Websocket Service now in public beta.

The first Qt Cloud Service, Enginio data storage, has been officially available since Qt 5.2 for all Qt developers. Since then, the progress has been amazing. There are several cloud applications built with Qt Cloud Services and new applications are launched every day. Qt Cloud Services really has brought new innovations and momentum to the Qt ecosystem. We have added a few success stories in our web site for you to see. Thanks to Ugmore, Octo3, Waplanner and RapidImages for sharing your success stories. By adding the Managed WebSocket Service, we are now lifting Qt Cloud Services to a new level. In addition, several improvements are visible in the dashboards, web site and documentation. You can find all these at qtcloudservices.com

What is Managed Websocket Service (MWS)?

Managed WebSocket is a fully-managed service implementing two-way, real-time communication gateway for WebSockets. It provides scalable APIs for any real-time chat, collaboration, notification, game or dashboard applications! Managed WebSocket provides connections between any clients or servers.

We have succeeded in designing the service to scale seamlessly along with your application needs. It provides virtually unlimited socket connections over redundant and reliable cloud platform.

You don’t need to worry about server backends, scalability or security issues. It’s all managed for you. We believe in that way you can better focus on things that really matter, like your business and applications.

How to get started?

Qt5.3 contains a new websocket module that is compatible with the Managed WebSocket Service. In  order to get started with your Qt application, please follow the getting started guides. You can also find a chat application demonstrating the functionality with the new websocket module. You can additionally make connections through REST API from any platform.

Managed WebSocket works, of course, together with the existing Enginio Data Storage for unified access control and policy. You can also configure Enginio web hooks to send notifications to the Managed WebSocket Service. This will enable clients to get notified in real time if there are any changes in Enginio data. This is very useful for connected applications that no longer need to poll if data is changed.

We are working on the managed WebSocket to add more documentation and examples. As always, any feedback is very much appreciated. See more at http://qtcloudservices.com/products/managed-websocket

If you have any questions or suggestions, you can always contact us via our support helpdesk or submit your question to the community forums. Thank you in advance.

Please note that all existing Enginio backends and Qt accounts are working normally without any interference.  The new Qt Cloud Services dashboard replaces the old Enginio dashboard and imports your enginio backends. It’s better than ever before as you can now also add Managed WebSocket to your cloud under your active subscription.

Qt Creator 3.1 RC1 released


We are happy to announce the Qt Creator 3.1 RC1 release today. We have been fixing lots of bugs during the weeks since the beta, and think that we are now almost ready. So, this is the call to all of you, to give it a try, and give us some more feedback!

If you haven’t followed the beta release, I highly recommend reading the corresponding blog post for some information about the new features in Qt Creator 3.1. There are two features in 3.1 that I haven’t mentioned there, and which I’d like to highlight here:

We ship a new, experimental plugin for WinRT development (only available on Windows). You can read more about it in its own blog post here.

The iOS plugin went out of experimental state, and is enabled by default now (only available on Mac OS X). It now supports QML debugging and profiling, and many things have been fixed and tweaked, for example you can set the simulated device in your simulator run configurations now.

You find the opensource version on the Qt Project download page, and Enterprise Customers find their package in 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.

Qt Weekly #4: Benchmarking Code


Qt provides several built-in ways to benchmark the runtime costs of code. Let’s have a quick glance at the most common ones.

There comes a time in every non-trivial application when performance starts to matter. In fact, it’s common for developers to pro-actively try to mitigate this by doing micro-optimizations, and aiming for optimized coding patterns based on ‘common wisdom’. However, hardware and compilers evolve, and soon you’ll get long discussions at the coffee machine about the best way to iterate, to pass arguments, and so on – and whether it matters in the end.

Wouldn’t it be cool to come up with some hard data in these cases? Qt provides a few simple ways to measure timing characteristics of code.

Qt Test library

The Qt Test library makes it very easy to create a benchmark. Even more so if you’re using the “Other Project/Qt Unit Test” project wizard in Qt Creator to let you generate the stub code that is needed. Then you’ve to just add the lines to be benchmarked inside the QBENCHMARK macro:

void BenchmarkTest::testCase1()
QBENCHMARK {
// code to benchmark goes here
}


The test will rerun the code inside the macro as often as it’s needed to get a somewhat accurate measurement. You can use e.g. the -iterations option as a command line argument to fine tune how often the test will run. If your code can’t be just repeated this way, you might have to use the QBENCHMARK_ONCE macro and -minimumtotal option to instead re-run the whole test case.

It’s also worth considering which back-end would best suit the use case: While ‘wall-time’ is the default and available everywhere, using the CPU tick counter (‘-tickcounter’ argument) to measure CPU ticks usually gives more stable measurements.

In any case, you should take care that the results are somewhat stable and meaningful. If you want to do some more statistical analysis of the data, you can use the -csv switch to import the results in a spreadsheet.

Tip 1: Always use release builds of Qt and your benchmark.

Tip 2: Make sure the code in QBENCHMARK has a side-effect, so it’s not optimized away by the compiler. A common practice is e.g. to write results to a ‘volatile’ variable.

QElapsedTimer

Using the Qt Test Library works well if the code you want to measure is self-contained. But what if you want to measure the runtime costs of code inside your application that can’t be easily ‘factored out’ to a test case? Qt has a number of timers, but the most useful one for benchmarking is QElapsedTimer:


QElapsedTimer timer;
timer.start();
slowOperation1();
qDebug() << "The slow operation took" << timer.nsecsElapsed() << "nanoseconds";

QElapsedTimer will use the most accurate clock available. This however also means that the actual resolution and accuracy of the timer can vary greatly between systems.

Tip 3: On Linux, the CALLGRIND_START_INSTRUMENTATION and CALLGRIND_STOP_INSTRUMENTATION macros can be used in a similar way to get even more accurate and stable results (based on CPU instructions executed).

console.time(), console.timeEnd()

Finally, there are also helpers in QML/JS to measure the time between two events:

console.time("loadPuzzle");
Logic.startNewGame(gameCanvas,"puzzle","levels/level"+acc+".qml");
console.timeEnd("loadPuzzle");

will print e.g.

loadPuzzle: 90ms

as debug output.

What else?

The API’s described here are simple and easy to use if you know what you want to measure. But they don’t help you much if you don’t know yet where to start. Tools like Valgrind/Callgrind, Intel VTune, Apple XCode Instruments excel at analyzing your complete program. For Qt Quick, Qt Creator ships a QML Profiler.

Qt Weekly is a new blog post series that aims to give your daily Qt usage a boost. Stay tuned for next week’s post!

Qt 5 Binary Overlays Available for BlackBerry 10

We’re happy to announce that life just got a little easier for Qt enthusiasts developing for BlackBerry 10!The Qt Project has made Qt 5 binary overlays available for BlackBerry 10 development. Developers can now add Qt 5 libraries to their existing BlackBerry 10 NDK installation to easily create Qt 5 applications.

Check out the documentation and download the overlays on the Qt wiki.

Note that these overlays are not part of an official BlackBerry release and are a package provided by the Qt Project to the community. The Qt 5 overlays cannot be used with Cascades development.

Questions about this update? Ask me in the comments below!


Qt Purchasing API 1.0 (Technology Preview) Released!

by Eskil Abrahamsen Blomfeldt (Qt Blog)


When the Qt 5.3 beta was announced, we mentioned the upcoming release of our Qt Purchasing API for Qt Enterprise and Qt Mobile users. We now have a technology preview ready for you to try, and we’re really excited to hear your feedback.

The technology preview is available as a source package from the Qt Account, and the documentation is available online. For the final release (which will be out around the same time as Qt 5.3.0), we will also make binary packages available.

What is it?
The Qt Purchasing API contains cross-platform APIs that can enable in-app purchases in your Qt application. There are C++ and QML APIs available, and it currently supports both consumable and unlockable in-app products. The backends that are currently in place is for Android and iOS, but we’d like to add more later, such as the Windows Store and the Mac OS X Store.

Note that there are no source or binary compatibility guarantees for this technology preview, as one of the objectives of releasing it is to get feedback on the APIs. We want to ensure that the APIs we release match the requirements of our users as much as possible, so it’s possible that they change based on the feedback we get.

How do I build it?
As mentioned, the technology preview is only released as a source package, so you will need to build it manually. Since this is a Qt module which needs to be installed into your Qt directory, it has a couple of requirements which are not requirements for building applications. For you convenience, I’ll go through each of the steps required for building the package in Qt Creator here.

  1. First you have to download and install a copy of the Qt 5.3.0 beta for your target platform, as the Qt Purchasing APIs depend on Qt 5.3.0. If you want to create an application that works on both iOS and Android, get the combined package for your Mac.
  2. Set this up, as instructed in the documentation: For iOS and for Android.
  3. Get the Qt Purchasing API source package, and unpack this in a location of your preference.
  4. Open Qt Creator.
  5. In Qt Creator, open the project “qtpurchasing.pro” in the directory where you unpacked the Qt Purchasing source package.
  6. Select the kits for which you want to use Qt Purchasing.
  7. In the Projects page, under Build Steps, open Details for Make. Add the word install in the line edit for Make arguments.
  8. On the same page, make sure you deselect the Shadow build option.
  9. If this is an Android kit, the PATH environment variable needs to contain the javac compiler executable. If it does not already, add it by editing the PATH variable under Build Environment. On Windows, for example, the directory could be something like C:\Program Files\Java\jdk1.7.0_15\bin.
  10. Build the project by selecting Build project “qtpurchasing” in the Build menu.
  11. added 2014-04-15: Due to a bug which was discovered too late, there’s an extra step required when building for Android on Windows: After the build has completed, you need to go into the library directory of the Qt installation you are using (e.g. c:\Qt\5.3.0beta\5.3\android-armv7\lib) and rename the file libQt5Purchasing.so.5.3.0 to libQt5Purchasing.so. If you do not do this, applications using the purchasing API will fail on startup.

If you get an error that says Error 1 (ignored) you can safely ignore it, as it says.

Once you have completed these steps, the Qt Purchasing API should be ready to use in the Qt version where you chose to install it. Note that you have to execute steps 7 through 10 for each of the kits in which you want to enable Qt Purchasing.

Qt Hangman Rebeefed
To demonstrate the new APIs, we’ve taken the Qt Hangman example and beefed it up a bit.

Qt Hangman running on an iPhone 5S and a Nexus 5.

Qt Hangman running on an iPhone 5S and a Nexus 5.

The example source code is provided in the Qt Purchasing package, so you can build it yourself and run it as you please. The game will work out of the box, but you will have to provide your own store listings for it if you want to enable the in-app purchases in your custom build. If you just want to check out how it looks, an updated version is also available in Google Play for Android and the iOS App Store.

Qt Hangman Store screenshot

The Qt Hangman Store provides different products for purchasing. Screenshot from Nexus 5.

The game’s UI has been revamped with vowel awards and a score, and a more sensible monetization model has been implemented where you can pay for either bundles of 100 vowels or to unlock infinite vowels.

Next steps
If you are using the Enterprise or Mobile edition of Qt, and are interested in including in-app products in your applications, please download the package and let us know what you think. We’re accepting feedback on Qt.Purchasing@digia.com. Don’t hesitate to contact us, either with suggestions on changes to the APIs or with bug reports!

update: Qt.Purchasing@digia.com should now be working properly. I apologize for the inconvenience.

Changes in the git branching model of Qt (April fool)


It’s been a while since Qt adapted git as its revision control system, and we’ve been experimenting with different branching models …

In Qt 4 (qt.git) we followed a scheme with one master branch, which gets forked into minor version branches (e.g. 4.8), which gets forked into patch branches (e.g. 4.8.1) … In the Qt 5 repositories we adopted a model where we had only three branches: dev, stable, release. This was aiming to make it easy for people to participate and submit patches, without having to worry too much about what’s right now the ‘right’ branch to submit.

As it turned out, the dev/stable/release branching model however makes the release process unnecessarily hard, which resulted in a proposal to move back to the original Qt 4 model. After some back and forth the Qt project however seems now to opt for a more radical approach: Changing to a novel, ‘one-branch’ model.

The current proposal on the open development mailing list that so far got unanimous support from developers is to have only one git branch, ‘qt’. This branch is at one point in time in different states, either in ‘dev’ state (allowing new features), ‘stable’ state (hardening), or ‘release’ state (for patch level releases).

The benefits of this approach are:

  • no ambiguity about where to put patches
  • no need to fork branches
  • no need to merge branches
  • ensures focus on the next release
  • less variants to be tested in Qt’s continuous integration system

This approach leverages on the distributed nature of git: You can keep your non-critical commits locally, until the window for new features is open again.

Do you have experience with such a novel ‘one branch model’? Are you aware of any git projects that follow the same model? Let us know!

Color Theory and the User Experience

Color theory is often referenced when creating or viewing traditional works of art. Using color to successfully portray balance, movement and atmosphere is crucial. A painter does not use color haphazardly, they use it with purpose. It is used to organize their composition, direct the viewer’s focal point and create an emotional impact. Can these general rules be applied to interface design? Can they help create a more meaningful user experience? The answer is yes!

Qt Developer Day China 2014, Beijing & Shanghai | Get a Free Pass Today!


I’m sure you are aware of the amazing annual gatherings for Qt enthusiast hosted in Berlin & San Francisco. But did you know we have other Qt Developer Day events around the globe as well? Qt’s popularity has been gaining in the Asian markets in the past year with a large following coming from Chinese-speaking countries and Japan, so we’re doing our best to bring the show to you.

Qt Developer Day China comes to Beijing, May 22 and to Shanghai, May 23. Registration is now open, so grab your free ticket today.

http://qt.digia.com/QtDeveloperDayChina/  (in English)
http://qt.digia.com/zh-CN/QtDeveloperDayChina/ (in Chinese)

Qt Developer Day Asia 2014 highlights:

  • Lars Knoll, Qt CTO, on the Qt Path – Where We Are & the Technology Direction Ahead
  • Qt Powering Your Internet of Things Connected Device Strategy
  • Tech Talks, Training & Insights To Make You a Power User: Intro to Qt and Qt Creator, Intro to Embedded Development with Qt Enterprise Embedded, Deep Dive into Qt Quick and Qt Quick Controls, and much more…
  • Integrating Mobile Into Your Cross-Platform Strategy with Qt

Share your findings about these upcoming events with the community, and start your dialog and networking today.

Don’t wait. Don’t procrastinate. Register now for Qt Developer Day Beijing & Shanghai!

If you’re in Japan, Qt Developer Day sets up in Tokyo May 20. Registration for Tokyo opens soon, so  there is still time to learn to read Japanese before you try to register.

If you are interested in being a sponsor and reaching hundreds most influential application and UI developers in Asia, please contact us at qt.info@digia.com.

Long Time no See (好久不見)

Almost a year ago I took my Qt/DirectFB Jenkins down. With that CI for MIPS/uclibc and DirectFB stopped being done (as far as I know). It was a difficult decision but it reflected my situation. I didn't do a Qt project for a long time and didn't have any Qt related work on the horizon.

My main work involves using Smalltalk (GNU Smalltalk and Pharo) and writing a lot of a C code for the various Osmocom/GSM related projects and the joy of integrating software to build  HW products. I didn't think I would use/write/develop using Qt anytime soon. For sentimental reasons I stayed on the qt-devel mailinglist (I still read it day to day) and followed the work done by Lars, Simon and all the others with great joy.

For an internal project of sysmocom I needed to parse, generate and stream (through HTTP) JSON content. I built a first prototype using GNU Smalltalk and the Iliad Framework. The system was quickly built and we were able to gain some experience with it. Given the amount of data we intended to pipe through the system we wanted to move to a fully compiled version (instead of spending the time tuning the VM). I decided to use the Json support of QtCore, QtNetwork for the HTTP client and planned to use libsoup as the HTTP Server. After some research I stumbled across Tufao and used that one instead and don't regret it. Thanks to QThread and queued signal and slots I was able to make use of more than one CPU core and the application was fun to develop.

I am a Unix Dinosaur so for the buildsystem I shortly considered using qmake but then ended up using autotools. Thanks to the autotroll m4 macros building Qt applications is not that bad. I decided against using cmake as it still feels backward (e.g. no config.log, most scripts don't use pkg-config but some hand rolled magic like the FindBoost thing).

We are building Debian packages using an internal OBS appliance and this way can easily update/deploy our software thanks to that. After deploying every couple of hours the application/thread would crash. The backtrace pointed to QNAM, deleteLater and QObject.. David Faure had documented and fixed various race conditions and after we upgraded our application to use Qt5.2 the crashes stopped occurring. The application was last re-started on the 5th of February and works quite reliable.

This month we started a simple REST server using Qt and Tufao. Maybe I should search for a nice Qt consumer related project too? Qt is definitely here to stay.

Tagged pointers, and saving memory in Trojita

One of the improvements which were mentioned in the recent announcement of Trojitá, a fast Qt e-mail client, were substantial memory savings and speed improvements. In the rest of this post, I would like to explain what exactly we have done and how it matters. This is going to be a technical post, so if you are not interested in C++ or software engineering, you might want to skip this article.

Planting Trees

At the core of Trojitá's IMAP implementation is the TreeItem, an abstract class whose basic layout will be familiar to anyone who has worked with a custom QAbstractItemModel reimplementation. In short, the purpose of this class is to serve as a node in the tree of items which represent all the data stored on a remote IMAP server.

The structure is tree-shaped because that's what fits both the QAbstractItemModel's and the IMAP way of working. At the top, there's a list of mailboxes. Children of these mailboxes are either other, nested mailboxes, or lists of messages. Below the lists of messages, one can find individual e-mails, and within these e-mails, individual body parts as per the recursive nature of the MIME encapsulation. (This is what enables messages with pictures attached, e-mail forwarding, and similar stuff. MIME is fun.) This tree of items is used by the QAbstractItemModel for keeping track of what is where, and for issuing the QModelIndex instances which are used by the rest of the application for accessing, requesting and manipulating the data.

When a QModelIndex is used and passed to the IMAP Model, what matters most is its internalPointer(), a void * which, within Trojitá, always points to an instance of some TreeItem subclass. Everything else, like the row() and column(), are actually not important; the pointer itself is enough to determine everything about the index in question.

Each TreeItem has to store a couple of interesting properties. Besides the usual Qt-mandated stuff like pointer to the parent item and a list of children, there are also application-specific items which enable the code to, well, actually do useful things like printing e-mail subjects or downloading mail attachments. For a mailbox, this crucial information might be the mailbox name. For a message, the UID of the message along with a pointer to the mailbox is enough to uniquely identify everything which is needed.

Lazy Loading

Enter the lazy loading. Many people confirm that Trojitá is fast, and plenty of them are not afraid to say that it is blazingly fast. This speed is enabled by the fact that Trojitá will only do the smallest amount of work required to bring the data over the network (or from disk, for that matter). If you open a huge mailbox with half a million messages, perhaps the GMail's "All messages" account, or one's LKML archive, Trojitá will not start loading half a million of subjects. Instead, the in-memory TreeItem nodes are created in a special state "no data has been requested yet". Trojitá still creates half a million items in memory, but these items are rather lightweight and only contain the absolute minimum of data they need for proper operation.

Some of these "empty" nodes are, eventually, consulted and used for item display -- perhaps because a view is attached to this model, and the view wants to show the recent mail to the user. In Qt, this usually happens via the data() method of the QAbstractItemModel, but other methods like rowCount() have a very similar effect. Whenever more data are needed, the state of the tree node changes from the initial "no data have been requested" to "loading stuff", and an asynchronous request for these data is dispatched. An important part of the tale is that the request is indeed completely asynchronous, so you won't see any blocking whatsoever in the GUI. The QTreeView will show an animation while a subtree is expanded, the message viewer might display a spinner, and the mail listing shows greyed-out "Loading..." placeholder instead of the usual message subjects.

After a short while, the data arrive and the tree node is updated with the extracted contents -- be it e-mail subject, or perhaps the attached image of dancing pigs. As the requested data are now here, the status of the tree node is updated from the previous "loading stuff" into "done". At the same time, an appropriate signal, like dataChanged or rowsInserted, is emitted. Requesting the same data again via the classic MVC API will not result in network requests, but everything will be accommodated from the local cache.

What we see now is that there is just a handful of item states, yet the typical layout of the TreeItem looks roughly like this:

enum class FetchingStatus {
    INITIAL_NOTHING_REQUESTED_YET,
    LOADING,
    DONE,
    FAILED
};
class TreeItem {
    TreeItem *m_parent;
    QList<TreeItem*> m_children;
    FetchingStatus m_status;
};

On a 64bit system, this translates to at least three 64bit words being used -- one for the painter to the parent item, one (or much more) for storage of the list of children, and one more for storing the enum FetchingStatus. That's a lot of space, given we have just created half a million of these items.

Tagged Pointers

An interesting property of a modern CPU is that the data structures must be aligned properly. A very common rule is that e.g. a 32bit integer can only start at memory offset which is a multiple of four. In hex, this means that an address, or a pointer value, could end with 0x0, or 0x4, or 0x8, or 0xc. The detailed rules are platform-specific and depend on the exact data structure which we are pointing to, but the important message is that at least some of the low bits in the pointer address are always going to be zero. Perhaps we could encode some information in there?

Turns out this is exactly what pointer tagging is about. Instead of having two members, one TreeItem * and one FetchingStatus, these are squashed into a single pointer-sized value. The CPU can no longer use the pointer value directly, all accesses have to go via an inlined function which simply masks away the lowest bits which do bring a very minor performance hit, but the memory conservation is real.

For a real-world example, see this commit in Trojitá.

Using Memory Only When Needed

Back to our example of a mailbox with 500k messages. Surely a user is only going to see a small subset of them at once, right?

That is indeed the case. We still have to at least reserve space for 500k items for technical reasons, but there is certainly no need to reserve space for heavy stuff like subjects and other headers. Indeed, in Trojitá, we track the From/To/Cc/Bcc headers, the subjects, various kinds of timestamps, other envelope items and similar stuff, and this totals a couple hundred bytes per each message. A couple hundred bytes is not much (pun intended), but "a couple hundred bytes" times "half a million" is a ton of memory.

This got implemented here. One particular benchmark which tests how fast Trojitá resynchronizes a mailbox with 100k of messages showed immediate reduction in memory usage from previous 45 MB to 25 MB. The change, again, does come with a cost; one now has to follow one more pointer redirection, and one has to perform one more dynamic allocation for each message which is actually visible. That, however, proves to be negligible during typical usage.

Measure, Don't Guess

As usual with optimizing, the real results might sometimes be surprising. A careful reader and an experienced Qt programmer might have noticed the QList above and shuddered in horror. In fact, Trojitá now uses QVector in its place, but when I was changing the code, using std::vector sounded like a no-brainer. Who needs the copy-on-write semantics here anyway, so why should I pay its price in this context? These data (list of children of an item) are not copied that often, and copying a contiguous list of pointers is pretty cheap anyway (it surely is dwarfed by dynamic allocation overhead). So we should just stick with std::vector, right?

Well, not really. It turned out that plenty of these lists are empty most of the time. If we are looking at the list of messages in our huge mailbox, chances are that most of these messages were not loaded yet, and therefore the list of children, i.e. something which represents their inner MIME structure, is likely empty. This is where the QVector really shines. Instead of using three pointers per vector, like the GCC's std::vector does, QVector is happy with a single pointer pointing to a shared null instance, something which is empty.

Now, factor of three on an item which is used half a million times, this is something which is going to hurt. That's why Trojitá eventually settled on using QVector for the m_children member. The important lesson here is "don't assume, measure".

Wrapping up

Thanks to these optimization (and a couple more, see the git log), one particular test case now runs ten times faster while simultaneously using 38% less memory -- comparing the v0.4 with v0.3.96. Trojitá was pretty fast even before, but now it really flies. The sources of memory diet were described in today's blog post; the explanation on how the time was cut is something which will have to wait for another day.

Qt Data Visualization 1.0 released


I’m happy to announce that we have now released the Qt Enterprise Data Visualization add-on 1.0 final. The main focus after Beta release has been further improving the existing functionality, improving documentation and examples and of course introducing binary packaging for easier installation to development environment.

As a recap of the functionality Qt Data Visualization includes:

  • Multiple data visualization options: 3D Bars, 3D Scatter, and 3D Surface
  • 2D slice views of the 3D data
  • Interactive data: rotate, zoom, and highlight data using mouse or touch
  • Uses OpenGL for rendering the data
  • Qt C++ and Qt Quick 2 supported
  • Customizable axes for data – control viewable data window with axis ranges
  • Customizable input handling
  • Customizable themes
  • Multiple options for data formats and fully customizable data proxy model

 


Changes between beta and final include:

  • Multiple series support for Surface graphs
  • 3D object rotation support
  • Added different rendering modes and multisample antialiasing for QML applications
  • Improvements in 2D slice view label positioning
  • Support for high DPI displays
  • New examples
  • Qt Quick Designer support (requires upcoming Qt Creator 3.1)
  • Easier installation through Qt Online Installer and Maintenance Tool

For further information about the functionality and more examples please take a look at the Data Visualization online documentation at: http://doc.qt.digia.com/QtDataVisualization.

Data Visualization is included in the Qt Enterprise and Qt Mobile Licenses, so it is free to use by all our licensees. You can test out the Data Visualization and the rest of Qt Enterprise or Qt Mobile by downloading a 30-day free evaluationQt Enterprise and Qt Mobile customers can download Data Visualization binaries and source code through the Package Manager in Maintenance Tool or the Online installer. The module can be found under Qt Enterprise Add-Ons in the package manager. Source packages are also available in Qt Account Downloads.

As always, the Qt Data Visualization is fully covered by our standard support. If you have any issues using them or want to share ideas for further development, just contact our support team through the Qt Account Support Center. 

Qt Weekly #3: Qt for Android – Tips and Tricks


The Qt installation packages contain Qt for Android libraries and useful tools for developing Qt apps for Android devices. However, you will need to install the Android NDK and SDK, and some other tools yourself and configure them for use with Qt Creator.

In this blog post, we’ll walk-through the Qt for Android development process, from the environment set up to the deployment to the store. These details are also available in the official product documentation: Qt documentation.

Besides the developement process, we will also discuss a few platform-specific findings that might be useful.

Setting Up the Environment

The getting started documentation gives you the setup instructions. Where to get the Android SDK, NDK, Apache Ant and JDK (or openJDK), and on Windows the additional minGW and Android Debug Bridge driver links.

Note: From Qt 5.3.0, the offline installer for Windows will also include minGW., so you won’t have to install it separately if you select it during the installation.

The following are a few platform-specific issues that must be handled for better development experience.

Linux 64-bit: Android SDK installation on 64-bit Linux machines (Ubuntu, Fedora) often doesn’t work out of the box. Running <PATH_SDK>/platform-tools/adb can return errors like:

  • Ubuntu: bash: ./adb: No such file or directory
  • Fedora: adb: /lib/ld-linux.so.2: bad ELF interpreter: No such file or directory or adb: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory

This is because the SDK comes with 32-bit version of the libraries. To fix this problem you can install:

  • Ubuntu: sudo apt-get install libstdc++6:i386
  • Fedora: yum install glibc.i686 glibc-devel.i686 libstdc++.i686 zlib-devel.i686 ncurses-devel.i686 libX11-devel.i686 libXrender.i686 libXrandr.i686

Windows: Consider installing the Android NDK in a “short” path. Otherwise, you may experience the following errors (or similar):

“mingw32-make: *** No rule to make target ‘..\..\..\..\..\..\..\android\android-ndk-r9b-windows-x86_64\android-ndk-r9b\sources\cxx-stl\gnu-libstdc++\4.8\include\profile\impl\profiler_map_to_unordered_map.h’, needed by ‘main.obj’.  Stop.The process “C:\Qt\Tools\mingw48_32\bin\mingw32-make.exe” exited with code 2.”

Due to a platform limitation, this issue can arise when the path is too long (QTBUG-37113). Try installing the NDK directly in the root with a short directory name, and have a shallow directory structure for the project you are building. If you still have problems, try turning off shadow building, as this appends a long directory name to your path.

Note: If your application is using OpenSSL, have look at OpenSSL support page.

Deploying to the Device

There are three aspects to consider when deploying an application to an Android device:

  1. Is my device successfully connected?
  2. What is required from the application side so the application deployed works as expected? (what to do if my application uses plugins, how do I use resources, and so on.)
  3. Which tool can help deploy the application to a device?

Before trying to deploy to a device, you should first enable USB debugging on the device. Follow the steps as described in the Android documentation:

  • On most devices running Android 3.2 or older, you can find the option under Settings > Applications > Development.
  • On Android 4.0, it’s in Settings > Developer options.

Note: On Android 4.2 and later, Developer options is hidden by default. To make it available, go to Settings > About phone and tap Build number seven times. Return to the previous screen to find Developer options.

On Windows, the default USB drivers must be replaced with the OEM USB Drivers. You can usually find them on the device manufacturers’ website. After downloading the relevant driver, follow these steps to update the existing USB driver:

  1. Open the “Computer Management” tool (Computer->Manage) and then navigate to System Tools ->Device Manager
  2. Right-click on your device and select “Update Driver Software…” from the context menu
  3. Follow the steps and use the driver you have downloaded

For the Nexus devices, you can install the driver using the Android manager (Android documentation).

  • Run <PATH_SDK>\tools\android.bat
  • In the “Extras” section select and install “Google USB Driver”.

To make sure that your device is successfully connected to your computer (1), run the following command and check that the device is listed in the output:

$ <PATH_SDK>/platform-tools/adb devices

For the tooling part (3), deploying an application to an Android device or emulator is very easy using Qt Creator. The following YouTube video demonstrates how easy it is to deploy a Qt application to several platforms using Qt Creator:

Preparing Your Application for Submission

Before you can upload your application to the store, you need to prepare it for submission.

Adding a Manifest File

The default AndroidManifest.xml generated by Qt is suitable for development testing, but cannot be used to submit the application to Google Play.

Create your own manifest by clicking on the Create AndroidManifest.xml button in Qt Creator. This is located under Projects, in the Run tab. Expand Deployment configurations to see it.

Once the manifest has been added to your project, you can modify it. Most importantly, set the application name and package name. The package name should be a unique identifier for your application. A convention is to use the syntax, com.mycompany.myappname, where the “com.mycompany” namespace is based on Internet domain ownership to avoid naming collisions with other applications.

Note: Package name cannot be changed after the application is distributed to users.

Other important parts of the manifest include the versionCode, which must be incremented every time you upload a new version of the application. Other properties will decide how your application package is presented in the store listing, such as the application name and version name.

For more information on the AndroidManifest.xml, see the Android documentation.

Signing the Application

When your application is ready and you want to upload it to a store, you need to sign the Release APK (Android Application Package) file with your own private key. Open the Deployment configurations and set up the signing information there. When you are done, select Release as the build configuration and deploy your project. Once the build is complete, you will find the APK file in the build directory of your project.

Regarding the signing certificate, Qt Creator allows you to create a new keystore if you don’t have one.

Note: Make sure you save this certificate for future upgrades of your application. If you loose the key and/or password, you will not be able to submit updates to your application. If you cannot sign an updated version with the same keystore that was used initialy, the user will install the new version as a completely new application..

Publishing to the Store

The first step is to get a publisher account if you do not already have one. Go to the Google Play developer console, log in with the Google account of your choice, and follow the steps as directed.

When you have set up your account, you can click on Add new application in Google Play’s developer console. Take a look at the Android documetation for more info.

Note: Once you have a signed release APK, you can also use it in other stores: Amazon Store, Ovi Store for Nokia X, Kindle Store, Samsung Store. Not all Android applications are compatible with these Android-based platforms, but most of them are. Also if your application is compatible, you usually only need some additional screenshots to submit your application to those stores.

Related information

  1. Qt for Android known issues
  2. Android deployment in Qt 5.2
  3. Update your application

 

Qt Weekly is a new blog post series that aims to give your daily Qt usage a boost. Stay tuned for next week’s post!

Help Test QtPrintSupport Changes in Qt 5.3 Beta 1

Significant changes have been made to the internals of QtPrintSupport in Qt 5.3 in an effort to resolve many of the page layout bugs and inconsistent behaviour across platforms, as well as preparing the way for printing on mobile devices and cloud printing in Qt 5.4 or 5.5. These changes were not in Alpha 1, but have now been merged for the Beta 1 release and need through testing to ensure they work properly with the wide variety of print devices and drivers out there.

The main changes on the painting side are:

  • A new QPageSize class in QtGui to abstract handling of page sizes and names, which supports 123 Postscript standard page sizes.
  • A new QPageLayout class in QtGui to abstract handling of page layout and paint rects in a consistent way, i.e. page size, orientation and margins.
  • QPdfWriter in QtGui uses QPageLayout to manage the PDF page layout, and you can now properly set the orientation of the PDF.
  • QPrinter in QtPrintSupport uses QPageLayout to manage the document page layout consistently between all platforms and the PDF file printer.

The main changes on the printing side in QtPrintSupport are:

  • A new QPA class QPlatformPrintDevice to abstract the print device handling, which will make new platform implementations easier.
  • The existing Win/Mac/Cups platform plugins have completely new print device implementations of the same full and consistent feature set on all platforms.
  • Mac now supports changing individual page orientation during a print job, and setting of Collate Copies and Document Name
  • Setting the Document Creator is now supported on all platforms
  • Mac and Win both now support setting of the Duplex Mode (not in beta 1, should be in final release)
  • QPrinterInfo has new api to expose more details about the print device. New api is provided to query for available printer names which should be faster than the old api that reurned QPrinterInfo instances and which could be slow when used across a network. You can query for the supported and default QPageSizes, with the old page size and name api being deprecated. You can also query the printer state, if it is a remote printer, if it supports custom page sizes, what the minimum and maximum physical paper sizes are, and what physical print resolutions are supported.

There have also been numerous other bug fixes and code clean-ups with more on the way, of particular note Windows printing now positions text correctly in relation to graphics.

An important note for Linux packagers is that QtPrintSupport now requires CUPS 1.4, which most distributions have been using since at least 2009, but this does mean that RHEL 5 will no longer be supported by QtPrintSupport.  Optional support for CUPS 1.6 is planned for Qt 5.4.

These changes in the backend are obviously significant, especially the full re-write of the platform code that talks to the physical print devices. While the code has been tested on a number of major-brand printers, the sheer variety of print devices and variable quality of print drivers (especially on Windows) means we need your help with the Beta to make sure there are no regressions or crashes. In particular, I'd like some real world testing on printers attached to remote print servers.

So how can you help? If you use the binary downloads, then you will need to build and test the examples found in widgets/richtext/textedit and widgets/painting/fontsampler, or just test with your own app printing code.  Check that the print dialog works correctly and the printed and PDF output appears as you would expect for all printers you have available.

If you build your own Qt, then you can run more tests. Firstly, use either Qt 5.2 or Qt 5.3 Alpha 1 to print out some "Before" documents for comparison purposes.  Run the following test/example code at different page sizes and on all your available printers, as well as printing to PDF:

qtbase/tests/manual/dialogs
qtbase/examples/widgets/richtext/textedit

Next copy the output of the following test to somewhere safe:

qtbase/tests/auto/printsupport/kernel/qprinterinfo

Finally, run the main auto tests to make sure the old code passes testing with your printers (if you have multiple printers you'll need to set each one to be default before running the test for it):

qtbase/tests/auto/printsupport/kernel/qprinter

Now build Qt 5.3 Beta 1 and repeat all the above steps, as well as the following new tests:

qtbase/tests/auto/printsupport/kernel/qprintdevice
qtbase/tests/manual/qprintdevice_dump

Look at the qprintdevice_dump output: do all the reported details look correct?

Play with the manual print dialog test: does changing the page sizes and other settings work, especially custom pages?

Compare the Before and After samples, easiest done by overlaying one on top of the other and holding it up to a bright light. There may be small differences, use your judgement to decide if they are better or worse.

If you have previously reported print layout bugs, then please retest these.  If you have your own code or app that uses printing then you can also test with that.

If you find any problems, then please open a bug at bugreports.qt-project.org and attach the output from all of the above, both before and after, and if possible scans of any printouts that look wrong to you.

In Qt 5.4, free time permitting, I'm planning to improve our support for print job and print settings management, and in 5.4 or 5.5 introduce support for cloud and mobile print services. I'm also looking at what bug fixes can be back-ported to Qt 4.8.  If that's something you'd like to be involved in, or your company might be interested in sponsoring development of, then drop me a line and we can get coding.

Qt 5.3 Beta Released


Great News! Qt 5.3 Beta is now available for download. Qt 5.3 Alpha was released about 3 weeks ago and I am really happy to announce that we now have the Qt 5.3 Beta with updated functionality and binary installers. 

Qt 5.3 is mainly focusing on quality and performance improvements, but we also have a nice set of new features available. With Qt 5.3 Beta we are introducing Beta support for Windows Runtime with final support for the platform coming in Qt 5.4. In addition, Qt 5.3 Beta also provides VS2013 binary installers.

Highlights of Qt 5.3 Beta include:

  • New QQuickWidget providing improved integration between Qt Widgets and Qt Quick
  • New Qt WebSockets module got added featuring full support for the web socket protocol (RFC 6455)
  • Major improvements to printing support
  • Major improvements for iOS and Android ports such as:
    • Better input method support for iOS (including also Chinese),
    • Positioning support for Android and iOS
    • Bluetooth for Android
    • …  and many more
  • Support for Windows Runtime platforms: Windows 8/RT (Modern UI), Windows Phone 8
  • New target binaries: Qt for VS2013 (32 and 64 bit, OpenGL and Angle), as well as Qt for WinRT and Qt for Windows Phone
  • Qt Creator 3.1 Beta included in the installers


For more details on what is coming with Qt 5.3, please refer to the Qt 5.3 Alpha release blog post, Qt Creator 3.1 Beta release blog post, and the list of new features in Qt 5.3.

Thanks to John Layt and others, significant changes have been made to the internals of Qt PrintSupport in Qt 5.3. These improvements should resolve many of the page layout bugs and inconsistent behavior across platforms, as well as prepare the way for printing on mobile devices and cloud printing in future Qt releases. These changes were not part of the Alpha release, but are now in and can be used with the Qt 5.3 Beta.

The new Qt WebSockets module provides a Qt API for implementing the web socket protocol. With web sockets, one can create two-way, real-time communication between client and server on top of a long-held single TCP connection. The protocol allows consistent behaviour across all platforms and enables use cases such as online collaboration tools, communication software, games and remote controllers.

Beta support for Qt for Windows Runtime

Qt 5.3 Beta is also the first time we are offering a binary release of Qt for Windows Runtime. Please check the blog post by Andrew Knight on what goodies we have to offer for those interested in addressing the Windows Runtime platforms. The intention is to continue developing Qt for Windows Runtime port towards the Qt 5.3 final and also in upcoming patch releases with the target of having this port fully functional by Qt 5.4. As mentioned, Qt 5.3.0 will provide a solid and supported beta-level functionality of WinRT in a similar manner as Qt 5.1 introduced Android and iOS last year: you can start working with it and deploy your Qt applications to relevant marketplaces, but some things are still being worked on.

More is Coming!

In parallel to Qt 5.3 development, we are also currently working on developing a new Qt Purchasing Add-On that provides a convenient Qt API for implementing in-app purchasing on iOS and Android applications. This will make it much easier than before to leverage in-app purchasing functionality for monetization in the  iOS AppStore and Google Play store. Support for Windows Store will be added later, as well as possibly other stores, such as the Mac AppStore. Following this Qt 5.3 Beta release, we will very soon release a Technology Preview of the new Qt Purchasing Add-On. The final version of the Qt Purchasing Add-On will be available under the Qt Mobile and Qt Enterprise offerings together with the final release of Qt 5.3.

Download Qt 5.3 Beta Today!

Qt Enterprise and Qt Mobile customers can download the Qt 5.3 Beta offline installer via the new Qt Account, which has replaced the Qt Enterprise Customer Portal. If you have not yet logged in to the new “Qt Account”, please make sure to reset your password first at http://qt.digia.com/loginportals/.  The Open-source version of the Qt 5.3 Beta is available via download.qt-project.org. As this is a beta release, remember some things may be slightly shaky, but your feedback is much appreciated to help make the final release a great one. We encourage everyone to try Qt 5.3 Beta. If you find some problem, please create a bug report. It is also good to check the known issues wiki page.

 

 

Bringing the magic of Qt to Windows Runtime


We’ve been hard at work on the Windows Runtime (WinRT) port and it’s about time we share a bit with all of you. For Qt 5.3, we’re releasing the WinRT port as Beta quality, with most of the Qt Essentials modules in functional form (including QML & Quick). We also have preliminary tooling support, so you can get started on WinRT as quickly as you would on any other supported Qt platform.

An API for modern devices

As a reminder, Windows Runtime is a new API largely tied to Windows Store Apps, or applications which run within the Modern UI environment. It has C++ bindings (among other languages), and can be used on Windows 8, Windows Phone 8, and Windows RT – running the gamut from budget smartphones to high-end PCs. That’s a lot of devices.

One of the most important things for us (and many of you) has been getting Qt Quick working smoothly on the platform. As you might guess, there are some limitations to getting such a stack working here. For one, the memory APIs which are commonly used by just-in-time (JIT) compilers (such as in QtQml’s virtual machine engine) are restricted and cannot be used by apps in the Windows Store (this is, of course, for platform security reasons; the same restriction is in place on iOS). Fortunately, the V4 virtual machine which premiered in Qt 5.2 has solved this problem swimmingly, allowing WinRT to utilize the interpreted codepath for these types of operations (albeit at the cost of some less optimal code execution speed).

Qt Quick up and running

Another issue we’ve faced is that WinRT doesn’t have a native OpenGL stack; it does, however, have Direct3D 11.1. As you might have guessed, the ANGLE project has largely solved the problem for us: Direct3D 11 support was added last year and is now in ANGLE’s mainline. We’ve built on top of this by adding WinRT windowing types to ANGLE’s EGL interface, and also made a few tweaks to support mobile GPU feature levels. The biggest hurdle, though, was finding a way to deliver pre-compiled shader binaries to our OpenGL (and Qt Quick) applications. While the traditional D3D compiler can be used on Windows 8/RT at development time, it isn’t available on Windows Phone (and it isn’t allowed in published apps for any WinRT target). That’s right – much like the restrictions on a JIT, there’s no runtime shader compiler available for Windows Store Apps. While inconvenient at times, offline shader compilation can contribute to a fluid user experience and reduced battery consumption.

SameGame on WinRTQt Quick Same Game running on Windows RT 8.1 (Microsoft Surface RT) and Windows Phone 8 (Nokia Lumia 920)

Our solution has been to introduce qtd3dservice, a background process which uses an inbox/outbox approach to compiling shader source files into shader binaries at runtime. When an app needs a shader compiled, it writes the source to a directory monitored by the compilation service, and the service compiles the source and ships a binary object to the device. These blobs are cached by the service, and can be packaged into the application (e.g. in a Qt resource file) for publication. While this “just-in-time” approach to shader compilation is suboptimal for packaging (the developer must run through their app to make sure all shaders are compiled), it allows for more dynamic shader possibilities at development time. In the future, we do plan to add build-time support for shaders (such as those used internally by the Qt Quick Scene Graph), to relieve developers of this extra packaging step whenever possible.

Pick your tools

With Qt Quick working reasonably well for most apps at this stage, we are improving tooling (as Oliver has already shared, we now have a Creator plugin). The same tools which power the plugin, winrtrunner and windeployqt, can also be used from the command line. Qt Creator support, no doubt, will continue to improve as we move toward the next release of Creator, and a “one IDE” developer experience is definitely in our sights. Even so, serious debugging will still require use of Visual Studio – so, you can either use Visual Studio to complement the capabilities of Qt Creator, or simply use Visual Studio exclusively.

Going forward

Between now and the Qt 5.3.0 release, we’ll keep on strengthening the stability of the port and the developer experience around it. For 5.4, we aim to improve module support, such as implementing backends for Qt Multimedia and Qt Positioning (we already have a Qt Sensors backend, though), as well as improving support for a native look and feel. Check out the Qt 5.3 Beta release, which offers binary installers for the port.

We’re very excited about adding yet another platform to Qt… if you haven’t gotten excited yet, perhaps a short video of the port in action will help sway you in the right direction:

Various Qt demos running on Windows 8.1, Windows RT, and Windows Phone 8

Disclaimer: Parts of the video are sped up to keep the energy level high. For actual performance, please try out the port yourself :)

Car Dashboard Project

It’s been quite a long time since I’ve posted here. To tell the truth I’ve been quite busy lately, and lazy when not busy. That doesn’t mean however that I’ve stopped hacking, or discovering new things though. At the beginning of the year, reading PlanetQt, I discovered the Automon Project Based on Qt, it allows […]