Frederik Gladhorn

Qt Fix and Polish Week

Published Monday September 22nd, 2014
6 Comments on Qt Fix and Polish Week
Posted in Community, Contributors, Test, Uncategorized

Last week we took a fresh look at bugs, examples and tests. Now the “Qt Fix and Polish Week” is over and it’s time to summarize. Most of the people working on Qt inside Digia participated, but it was especially great to have many people join us on #qt-bugs and contribute. On Monday morning we had a quick sync round to split into teams. Each team had a defined goal and much work got done.


In the bug triaging and fixing track we got our hands dirty to fix issues in all areas. For some of us inside Digia this also meant getting to know parts of Qt that we weren’t as familiar with and a great opportunity to exchange knowledge while working in a different setup. This is something we certainly will repeat – do an effort to work across teams to be even more efficient in bug triaging and fixing and getting an overview of the situation for Qt 5.4. We closed many bugs, and hopefully some of you out there saw your own reported bugs get fixed.

Qt comes with a lot of examples. We continued the polishing effort of them that we already had started on some time back, and focused on a few of them to have them shine on all platforms and make sure they give a good first impression, for example when running Qt Creator for the first time. There was a huge list of suggestions that got done, from improving the color scheme to making things work on Android and iOS devices. The task is overall so big that it is still ongoing, but last week was a great start getting people involved in the work.

Auto tests and QA
The original focus of the test fixing team was the reliability of the continuous integration (CI) system. While the system helps us deliver a well tested and stable Qt by make sure the huge amount of tests run without failure for every change that goes into Qt, a few of the tests sometimes result in that the CI doesn’t run as smoothly as we’d like it to. A lot of discussions took place on how we can improve our tests and the CI in general. We had many small initiatives to fix different parts, and to stabilize, fix and re-enable tests. The results are now becoming visible as the fixes make it through the CI.

Feedback about how to arrange differently next time? Please let us know!

Hopefully we’ll be able to coordinate and announce better and earlier the next time we arrange such an event. We will likely focus only on bug fixing, and we will coordinate using IRC again.

Already on Friday afternoon we had a wrap-up session in Oulu, Berlin and Oslo. We concluded that we had had good progress, and that this is something we would like to repeat, maybe for each release. It was great to see people from the community outside Digia join. Especially the “yeahhh submitted my first patch to Qt” on IRC was nice to see, and hopefully we also helped more people get started contributing to Qt and scratching their own itch!

Thanks a lot to all participants!

Cake with Qt logo and bug on the icing

Do you like this? Share it
Share on LinkedInGoogle+Share on FacebookTweet about this on Twitter

Posted in Community, Contributors, Test, Uncategorized


Violet Giarffe says:

Is there any way for me to attract attention to my old report on a game-breaking bug? I’m sick of still having to use Qt 4.8 with all its limitation (no C++ 11 on Windows, problems with Xcode 6 on Mac etc.).

Here’s the bug report:

Frederik Gladhorn Frederik Gladhorn says:

@Violet: The link you posted is to a bug that is closed, so it won’t receive any attention any more. This blog is also not the place to discuss individual bugs. Please use for support or if you have a fix or want to look at it yourself, feel free to contact the mailing list or use IRC, we are always happy to help people fixing bugs.

Benoit says:

I am getting more and more impressed by Qt development. Bug reports are usually addressed very quickly (at least for the more important ones) and almost all changes are done with unit tests.

The only thing which seems to be missing is a real indication about code coverage (would be great to get some stats). Also until now, even if I am very much satisfied with the testing capabilties (using QTestLib but also Quick Test, which we are using more and more), I could not find any tool to check code coverage of QML code. Is there something ongoing in that area?

Keep up the good work!

Frederik Gladhorn Frederik Gladhorn says:

@Benoit: For C++ code coverage of Qt you can compile with a gcov switch (on Linux at least, I think it’s a configure option). We also had some statistics provided by Froglogic recently (Squish Coco). For your own applications it should be relatively easy to use any available coverage tool. I’m not aware of any code coverage for QML at the moment, it sounds like a good addition though.

lasconic says:

I believe I’m the author of the now infamous “yeahhh submitted my first patch to Qt” 🙂
Glad you like it. I hope it will be the first of many. Help on #qt-bugs was perfect.

Vivek says:

@Frederik: I don’t know if this is the right place to ask this question. But i wanted to know how mature is accessibility support for Qt Quick based apps. Also, i am able to get it working using orca screenreader for native controls but it’s not working for custom controls. There is not much documentation apart from Your response will be of great help.

Commenting closed.

Get started today with Qt Download now