Planet Qt - Highlighting Qt development and applications

Day one of the Qt Day in Florence, Italy is sold out. The agenda for the day is dedicated to the use of Qt in Italy from a technical as well as business perspective.

Italian business leaders such as Alberto Ciarnello from Telecom Italia and Mario Fumagalli from Mixel have been telling us about why Qt has been a compelling choice for them. We have also heard  Italian Qt developers Easy Digital present their shipping Qt based Set-Top Box, and Qt Partner M31 will be demonstrating its Qt-based automation framework.

The conference is organised by Qt Partners with Develer in the lead cooperating with M31 and Digia and Nokia. The set-up of the event is similar to Qt Developer Days and Qt Developer Conferences with its mixture of technical tracks and Qt-in-use sessions. However, this event in Florence is focused on the local developer ecosystem with over 30 sessions delivered mainly in Italian.

During the morning, Nokia’s Manuel Reverte-Castro, Head of Ecosystem Developer Experience for South Europe, took us through the Qt opportunities in the mobile space, providing various examples of developers and companies that make money with Qt on the Nokia store. Burkhard Stubert, from Nokia, also delivered an engaging keynote session about Qt 5 and the Qt Project, and how you make a good ROI from targeting multiple platforms with Qt.

Digia will present the Qt Commercial roadmap and their focus on enhancing Qt for desktop and embedded development pushing forward features and functions that benefit cross-platform development on non-mobile targets.

Developers at the event can take advantage of a real-time help desk staffed by Qt engineers, learn more about licensing, as well as how to become a Qt Ambassador or to sign up to be a Qt Partner.

Tomorrow will feature even more technical sessions, and a fully-fledged community day. We’ll be bringing highlights of both days to you in the coming days.

To learn more about the event, visit http://www.qtday.it

The event also has its own Twitter account – follow @QtDay on Twitter (event hashtag: #QtDayITA)

Qt does not sell mobiles. As a consumer, Qt is a technicality. Right now, the experience and availability of apps sell phones. Qt is just a tool for us developers to implement those experiences. Despite this, it is interesting to compare the Nokia N9 and the new WP7-based Lumia handsets. The market’s reaction to both, and the irony of it all.

Sweden is a highly developed smartphone market. Almost everyone has a smartphone. Flat rate data subscriptions are cheap. Both N9 and Lumia are sold here, and are advertised.

The reviews are interesting. In mobil.se’s comparison, the N9 lose out because the platform is bound to die, thus have fewer apps. In the same organisations yearly awards, the N9 win three out of four applicable categories (the Sony Ericsson Mini Pro won the value-for-your-money-award). The N9 also went straight to the top of the selling charts at katshing.se, and in the telekomidag.se review of Lumia, the final words praise the N9 “Sister model N9 with MeeGo was a (albeit late) eye-opener, for Lumia is feeling more of oh well-character. Skilled in every way - but we have seen most things before.” (google translation of ”Systermodellen N9 med Meego var en (om än för sen) aha-upplevelse, för Lumia blir känslan mer av jaha-karaktär. Kompetent på alla sätt – men vi har ju sett det mesta förut.”)

Following this trail, the latest sad figures from Nokia report that things aren’t going that well. Telling your customers and employees that your current unique product is dead, then delivering a mainstream product later does not help improve business. Bloomberg has looked at various analysts’ estimations of sales figures, and they estimate 1.4 million N9 where sold 2011, while the Lumia is estimated to have sold 1.3 million (estimates range from 800k – 2M).

The interesting part in all these comparisons is that the N9/MeeGo platform is not being pushed by Nokia. They do not want to sell it. The Lumia, on the other hand, is being pushed by the biggest marketing budget Nokia ever has spent on a single product. The Lumia series is being expanded, apps are emerging.

I am sure that Nokia/Microsoft will succeed. I had a VHS system at home, even though Betamax was technically superior. The cost for success will be to turn Nokia from a leading brand into a mainstream supplier, no more important than HTC or Samsung. Sad for Nokia, sad for Finland, sad for what could have been for Qt. Launching N950 alongside N9 and following up with multi-core models would had been great. Also, seeing that MeeGo Harmattan more or less was Maemo with Qt, Intel’s drop-out would not have been the end of the world.

Still, from a Qt developer, this, in combination with the openly governed Qt Project means that Qt will stay a cross platform tool. The risk of seeing it being sucked into a life as a (great!) single platform is no more. Qt/iOS, Qt/Android and Qt/MeeGo give a bigger target area than WP7 has. And if the WP8 platform is to follow desktop, Nokia just jumped from one burning platform to another, since they are going HTML5.

It’s impossible to do every single thing perfectly when opening up the whole development of Qt. Hence the Qt contribution process has to be improved, helping everyone to make Qt even better. I’ll highlight some the suggestions brought up at Qt Contribution Days. Here is my take on a Troll approach on how to achieve excellence and learning how to make Qt even better than today.

“How can we do this better? Can it be done in a simpler and more elegant way?” are two key questions which have governed the people who have developed Qt from the start. The same goes for learning. We never stop learning. Trolls like to teach themselves new things and learn from each other. A well-meant error is also also key to achieving excellence. We thrive on change and achieve excellence through trying and failing. A well-meant error, on any level, should never be punished, because it is an opportunity for us to learn and improve. Being a contributor to Qt, the values on learning and excellence apply to you too!

Ideas for the contribution process

Several topics at Qt Contributors Days addressed improvements needed to the process, and how to make the contribution process easier. I’ll highlight three of the most significant ones, and urge you to add even more suggestions for improvements at this wiki: Improving The Qt Contribution Process.

The first noteworthy contribution process suggestion at Qt Contributors Day related to making better documentation on porting Qt to a new platform. Using Qt Lighthouse, porting is easier. But it’s still an expert challenge to adapt to a new operating system or platform. Having a migration overview, an architectural guidance, some experiences, would be really appreciated. The notes from the round table on porting challenges between Qt4 and Qt5 explain this idea further.

There are a lot of new contributors joining the Qt project. Having an overview of different activities, module maintainers and such can be time consuming. In some cases you might be even a detective trying to find status and were to begin. A Qt module activity overview inspired by Canonicals Launchpad could address the need for an overview. Aggregating module data from Qt commits, e-mail lists and relevant blog posts on a status page. This includes a list of who has contributed to the module, and who the maintainers are.

Cornelius Schumacher had an interesting suggestion for making a repository automation for Qt add-ons, making it really easy to use complementary libraries. Schumacker labled this as “CPAN for Qt”: a website listing available Qt-based libraries, making it easier for developers to find useful libs and for library developers to promote their work. It’s a really interesting project which can help foster an ecosystem of Qt add-ons.

These are only three humble suggestions on how to improve the Qt and the contribution process. There were of course more issues and features suggested at Qt Contributors Day. I hope also you will contribute your suggestion. Please use this wiki-page suggesting improvements.

About a year ago, I wrote a small web browser, called De Vicenzo just for fun.

But hey, someone went and madeit useful for something! Specifically, to provide previews when doing sphix docs

That's cool :)

While I was working on Qt at Nokia I spent a lot of time reviewing patches from colleagues.

Peer reviewing is an important step, and there is a reason why we do it in Qt.
Code in libraries (such as Qt) requires much greater care than application code.
The main reason is that you need to maintain compatibility for your users. You want to avoid regressions in your library, so code that works continues to work, even if the user did some hack or trick. For the user of the library, it has great value to be able to upgrade it without too much effort. A subtle behaviour difference in the library might introduce a bug in the application that might be really hard to track in the millions of old lines of code of the application.

Reviewing changes starts by looking for obvious mistakes and incompatibilities with the project guidelines:

• Is the code style correct?
• Is the code (auto)tested?
• Are the new APIs properly documented?
• Does the code follow the project policy? (Thread safety, no static global objects, no exported symbols without prefix, No use of features not supported by a supported compiler, ...)

The hard part of the review is seeing the things that the author of the patch could not possibly know.
It takes someone already familiar with the code to do the review. Someone who knows how the code interacts with the other parts, someone who knows the rationale behind some of the part of the code.
Even if you are familiar with the code, you almost always need to open the IDE and browse the existing code and the code it interacts too. Making a review by just looking at the patch may be possible for trivial compilation fix, but in almost all case of non trivial code, you will need to open the relevant files on your IDE.

There is so many things to check and to be aware of: code calling virtual functions, code used for other use cases than the one of the bug report, ...
You also need to think hard about what the patch might break and what the behaviour changes are.

As an example, let us take someone who does a change in a QComboBox to fix a usability glitch on Windows. Someone not familiar with QComboBox might not know that it behaves very differently depending on the style. The reviewer will likely to be able to spot that a change will "break" that style.

Another example is someone who identifies that a bug is caused by one wrong condition in an if clause. Changing seems to fix the problem. But why was that condition there? If the code is not commented and the history of the code shows it is very old, no relevant information can be deduced. The reviewer should be the one who knows that this condition is there to test a very specific use case that might or might not be required anymore.

Inside Nokia we used to have an internal Pastebin website for putting up patches. Nowadays the Qt Project is using a much more advanced process for reviewing.

I started a new coding hobby project today. But instead of actually getting very far with the productive part of the project I got side tracked on something fun I wanted to try out (don't you just love when that happens That's not possible when coding at work...). I wanted to share this day's outcome with you.

Read more on Sunday evening fun: Windows Phone 7 styled progress indicator in QML...

Technorati Tags: qml, Qt, qt quick, wp7. windows phone

It took us a while to transform the Maliit project into a real opensource project. At first there was only public code, later some wiki pages @ meego.com together with constantly changing components in the official MeeGo bugtracker, then a public mailing list.

After that we tried to become independent of MeeGo, but neither freedesktop.org nor the GNOME project could give us a suitable home. So we had to go with our own infrastructure in the end, which probably was the best we could do, in any case. We now enjoy our own website (mostly a wiki, for which we can also analyze the traffic), our own IRC channel, our own public bugtracker, our own mailing lists and a build bot. We also make use of other services such as launchpad.org and the openSUSE Build Service, both for packaging but also as part of our continouous integration setup. Both services provide nightly builds for Maliit, for example (though we still lack packages for ARM).

But there was always one thing missing: T-Shirts. Now that this is solved, too, we can finally call Maliit a real opensource project ;-) Hopefully we'll soon have another group photo of the people who've been involved in the project over the years. I'll make sure to bring a couple of T-Shirts to FOSDEM, so make sure grab Jon or me if you want one.

Image source - scribus.net

Version 1.4.0 of the popular open source desktop publishing program, Scribus, was released recently. This is great news for the community at large, but it also is a mark of pride for the Qt team.

The new version of Scribus has moved to Qt 4, “tuning for cross-platform compatibility” and taking advantage of some of the best new features in Qt 4.7.4 including Qt Quick, improved image caching technology and Qt Creator.

For the uninitiated, Scribus is a professional page layout tool with press-ready output to PDF files. Underneath its modern and user-friendly interface, Scribus supports professional publishing features, such as colour separations, CMYK and Spot Color support. It is available for Apple Mac OS X Leopard (or higher), Linux as well as Windows 32 and 64-bit machines under the free and open source General Public License.

Writing on their own developer blog the team notes, “Thanks to the port to Qt 4, the Scribus Team now also provides install files for Mac OS X 10.5 or later (DMG or pkg format), as well as a native version for OS/2 Warp 4 and eComStation. Additionally, thanks to feedback from users of other UNIX platforms, Scribus will build and run on more of those platforms as well.”

Scribus use cases are many and varied and the software has been used to create everything from CD cover sleeves and booklets, Swiss mountain village tourist brochures right up to professionally presented magazines.

Projects like Scribus are one of the key motivators for those of us here who work on Qt. Seeing quality programs being developed using Qt give us a boost in our work. We love to hear about projects like this, so if you have a cool project, whether its open source or commercial (or somewhere in-between) let us know. We might even feature you here on the Qt blog!

Overview

This is an awfully dry post; dry to the sheer logistic nature of it. This functionality exists and is quite straight forwards to stumble upon. This blog exists in order to draw your attention to it and hopefully minimize the stumble time.

You have a device:

1) Running an ssh server
2) With gdbserver

You also have:

1) A functional tool chain for the target (Code Sourcery is the traditional goto)
2) A Qt build for your target
3) A Linux box you are deploying from (My convenience, instructions should be readily repurposeable for Mac based developers)

Creator has various merits which basically speak for themselves.

Convenient remote visual debugging/profiling
Convenient (single click) deployment

You grow accustomed to this functionality if you target any of the officially/unofficially supported targets tightly integrated into Creator in its various distributions. (Official SDK, Necessitas, Meego SDK). It would be lovely if it were more commonly perceived as a generic end to end solution for deployment to generic Linux targets, and it is readily achievable if you avoid a couple of snags.

Initial configuration

Launch Creator
Menu -> Tools -> Options

Build & Run -> Qt Versions

Add your Raspberry PI Qt build: /opt/dev/qt-qpa-5-rasp-pi/bin/qmake

Creator indicates “Qt version 5.0.0 for Desktop”, this can be safely ignored.

Build & Run -> Tool Chains

Add your cross compiler: /opt/toolchains/arm-2010q1/bin/arm-none-linux-gnueabi-gcc

in my case. Adjust the ABI in the unlikely event it is incorrect.

Linux Devices -> Device Configurations

Add configuration with correct ssh details, deploy a public key and establish this works.

Per project configuration

1) Open an existing Qt application (example suffices)
2) Select a desktop build

Once this is done:

Projects -> Targets -> Build

Specify your target’s Qt version
Specify the toolchain from the drop down below

Projects -> Targets -> Run

Deployment

Method: Deploy to Remote Linux Host
Device Configuration: Select your “Linux Device” added in the Device Configurations step above

Run

Run Configuration: foo (on Remote Device)
Arguments: -platform eglfs

This should suffice, you should now be able to deploy, run and debug applications on the Raspberry PI (or any other similarly capable Linux based target)

A screen grab demonstrating the logistics is available here

A video where I talk through the steps is also available for those willing to weather my accent