Last May we had the first Qt Wiki Week, where we worked on making the Qt Wiki more readable and improved the place overall. And the frontpage got a major overhaul by Wieland.
The week was fun and now we are doing it again. The second ever Qt Wiki Week will take place two weeks from now, starting Monday 21.3.2016.
The Qt Forum Wiki discussion area is the place to bring in ideas to improve the Qt Wiki and things to do during the week.
You can participate from anywhere, and help make the Qt Wiki a better place for everyone from beginners to hard core Qt developers!
Qt, KDE, VideoLAN, Free Software Foundation Europe and KDAB teaming up to bring you QtCon.
QtCon is not just this year’s major Free and Open Source event in Europe for participants with an interest in Qt, but also a unique forum for talks and knowledge sharing in a state-of-the-art environment. We are bringing together our annual events KDE Akademy, VideoLAN Developer Days, Qt Contributors’ Summit, FSFE Summit and KDAB Qt training day under one roof.
2016 is a special year for many open source projects: KDE has its 20th birthday along with Free Software Foundation Europe and VideoLAN having their 15th birthdays. There will be celebrations!
The dates:
1st September — Qt Training Day by KDAB
2nd – 4th September — QtCon with multiple tracks of interesting talks for everyone
5th – 8th September — KDE continues with Bird of a Feather (BoF) and coding sessions
The call for talks and workshops will be published later in the spring.
We will have a maintenance break on the Qt Forums early Monday morning 8.2.2016, starting around 7.00 CET.
The target of the break is to do a major version update and do some cleaning of the database at the same time.
The break will last an estimated three hours, so we should be back online at aroung 10.00 CET. We’ll be updating the status on twitter as we get things done.
We start the introduction of the 2015 Qt Champions with Iori Ayane who is an active participant in the Japanese Qt scene.
Qt is big in Japan, Iori is the second Japanese Qt Champion in two years. There is a really impressive community of Qt users in Japan with regular meetups and activities.
Iori first saw Qt at a workshop in Nagoya in 2011 held by Suzuki-san (Qt Champion 2014).
The thing that really resonated for Iori was Qt Quick, which he immediately started using after the workshop and hasn’t stopped since.
Among the projects he has made are:
a Twitter client, that he used as an introduction project for himself. It started off as a Windows Mobile project, but worked on multiple platforms including all desktop platforms, Android and Meego (Nokia N9)
A space invaders style space shooter, that was coded in under a week. (The graphics are fan art for Madoka ☆ Magica, a Japanese anime)
An Android custom theme viewer application, used for viewing Android custom themes on the PC while you create them. It works with a Japanese custom Android ROM.
A tool with which you can play web games and easily share screenshots from them to twitter. It’s a web browser with tools specifically to take screenshots and share them.
While Iori has coded a lot, the thing that sets him really apart is that he has written several books on Qt in Japanese. This also started much like his coding with Qt Quick. After coding with Qt Quick for a while Iori felt that Qt Quick is such a wonderful technology that it should be more widely known. However there were no books in Japanese at the time. Iori had written about Qt Quick on his blog, but it felt limited, so he wrote an introduction to Qt Quick in Japanese and got it published with the help of friends.
Iori presenting Lars Knoll with his books at Qt Contributors’ Summit 2015.
On top of all that Iori has also been translating the Qt Installer Framework to Japanese and last year he started committing patches to Qt based on his translation. As a side project from the Qt Installer Framework work, Iori has written a book on the Framework and it has also been published.
The thing that has really impressed Iori in the Qt Community is that everyone is accepted as part of the community. The Japanese Qt community has grown as more people know about Qt and they have regular meetups and workshops in several locations.
Iori himself started with just making small hobby programs and has now made several books and patches to Qt. He likes to tell people about Qt and how easy it is to get started with Qt.
Again, congratulations to Iori on the title of Qt Champion 2015!
In addition to talking about the Push with Ableton, we had a chance to talk about joining the Qt Project as a contributor.
Ableton started contributing to Qt last year, what was the thing that got you started?
Working closely with the Qt Project is part of the Ableton Open Source strategy. It is just a natural step! Our products are invested in the Qt technology and it is unlikely that we will switch GUI frameworks in the coming years. Sometimes we hit the limits of Qt and we file specific bugs whenever we can, so becoming more involved with larger initiatives will help us ensure that Qt addresses our needs in the future.
We have already been working on contributing patches we made to Qt during our development process, some of which will be released as part of Qt 5.6 and 5.7, depending on when they reached the Qt repositories. The contributions to date have been related to QML plugins and use of QAbstractItemModel from QML. We expect to be able to make more significant contributions soon.
What would be an easy way to start contributing to Qt?
Filing bug reports is an easy way to contribute to Qt. Responses to bugs don’t always result in fixes in Qt, but sometimes result in good ways to redesign, using QML in a more-idiomatic way to avoid the bug. Adding minimal representative test cases with bug reports helps with getting quality responses from Qt developers.
Code contributions to Qt are a little bit more complicated, but the process of using gerrit is well-documented. We already use Git at Ableton, so from a tooling point of view, we didn’t have much more to learn after signing the Contribution Agreement.
Attending the Qt World Summit and previously the Qt Developer Days was a useful way to get in contact with Qt engineers to review some of those contributions.
Any tips for other companies that are thinking of having a stronger presence in the Qt community?
Start, then iterate. Filing quality bug reports is an easy and cheap way to begin exploring the community and to start to identify the people working on various areas of Qt. Reading the development mailing list and some commits in the Git repos also creates a broader picture of how Qt is made.
From there it’s just a case of turning from an accessor into a mutator. Getting to grips with Git and the contribution process is a hurdle, but it comes with the reward of not having to carry fixes or feature extensions in external patches.
Beyond that, a company needs to examine the benefits, come up with a strategy and think about how that presence fits into the structure of the organization.
What do you see as the benefits to Ableton in being present in the Qt community?
A recent blog post by Andy Wingo relates this to Conway’s Law, namely “To minimize your costs, you must somehow join the community of people that make your dependency”.
Contributing helps us to make more coherent software by ensuring that Qt has the interfaces we require and also by ensuring that we use the interfaces correctly and stay up to date with development and new releases. It is important to us that Qt is not a read-only black box.
Have you been active on the forums and mailing lists? Do you use them as information sources?
The forums and mailing lists are often good places to find information and best practices relating to Qt, but our engineers are not currently active in them. Often we find it is easier to walk to a knowledgeable colleague to ask a question instead of posting to the forums.
We expect to become more active on the development mailing list to discuss design issues relating to features we contribute.
How do you see the community being able to work together with you?
We are hoping for feedback on the design and implementation of code we submit to Qt in order to learn more from the experts. Unfortunately, a lot of the code which goes into Ableton products is not Open Source so we can’t get direct feedback on all of it, but it would also be great to get some feedback on the libraries we have already published for the community on Github.
One of those libraries, Aqt-Stylesheets was presented at Qt Developer Days 2014 and awarded the ‘Most valuable lightning talk‘.
The Aqt-Cassowary library is generally useful for particularly dynamic layouts and we think it fits well into the QML design model.
How do you balance work on the product and work on Qt?
We’re still trying to figure that out.
Our priority is to create the best quality products we can. There are already some cross-sectional teams in Ableton which work on internal libraries, and an extension of that structure might work for our Qt contributions. To date our contributions have been individual stories in our planning as needs arise. Adding the right balance of structure to that is something we would like to hear other opinions about in the comments!
Again, thank you very much for the discussion, it has been a pleasure to learn how Ableton is present in the Qt community and about the Ableton products.
Thanks again for taking the time to feature us on the Qt blog. We look forward to review feedback from the Qt contributor community, engaging in design discussions about use of Qt/QML in products like Push and our open-source offerings!
As the year is coming to an end soon, it is time to announce the 2015 Qt Champions!
Qt Champions are the people who go the extra mile for Qt. They do amazing things and surprise you with their dedication to Qt.
As last year, we have four Qt Champions for 2015. The number is not fixed, but these four nominees have made a big difference in the Qt community in 2015.
Without further ado, the Qt Champions for 2015 are:
Jürgen Bocklage-Ryannel and Johan Thelin for their work on the Qt5 Cadaques book. The Qt5 book covers all the aspects of development with Qt5 with an emphasis on QML. The book is freely available under a Creative Commons license for anyone contribute to and download and it has been translated to several different languages. Jürgen and Johan together with other community members helping out have created an excellent resource for developers who are starting their journey to Qt.
Iori Ayane for his many books on Qt and active participation in multiple areas of the Qt community. Iori-san has written multiple books on Qt in Japanese. He is also very active in the Japanese Qt scene, and during the last year he has also started contributing patches to Qt! All this makes for an impressive contribution to the Qt community.
And last, but not least, Samuel Gaist, who has continued his incredible activity on the Qt forums. He has also stepped up his activity on the bugtracker and code contribution side of the Qt project. Altogether his continued participation level is so impressive, that he is being nominated a lifetime title of Qt Champion.
Every new Qt Champion will receive a one year full Qt commercial license in addition to special Qt Champion items and invites to major Qt events during 2016.
Congratulations to all the new (and old) Qt Champions!
We’ll be telling you more about the Qt Champions and what they have done in the Qt community in January.
Berlin-based music company Ableton recently released the new Push, a digital instrument to create and perform music. It is a really impressive tool, take a look:
As the Push UI is built with Qt, we had a chance to ask Stephen Kelly, Benjamin Jefferys and Nikolai Wuttke – developers at Ableton – about how it was built and how it works.
Ableton has been around for a long time, where did it all start?
It all started in an apartment in Berlin back in 1999. The three founders –Gerhard Behles, Bernd Roggendorf and Robert Henke – wanted to create an alternative to the linear workflow of established DAWs (Digital Audio Workstations). In 2001 Ableton released Live 1 and moved into the workspace that we still occupy today – just a few streets from the apartment where the first lines of code were written. We have since released nine major versions of Live, and in 2013 we announced our first hardware instrument: Push, which was designed by Ableton but manufactured by Akai. This was well received by the community, but we wanted to evolve the concept so we completely redesigned Push and took hardware engineering in-house. We released the new Push at the beginning of November, together with Live 9.5 and Link.
You mentioned Live and Push, can you give a short overview of the different products you have, and how Qt fits in there?
We make three products: Live, Push and Link. Live is software for creating musical ideas, turning them into finished songs, and also taking them onto the stage. Push is a hardware instrument that puts everything you need to make music with Live at your fingertips. We’ve also recently developed Link – a technology that keeps devices in time over a wireless network. It is embedded within Live but it is also inside an increasing number of iOS music-making apps. The new Push is our first released product using Qt technology – for its animated display.
Can you give a general overview of the architecture used in Live/Push?
The updated Push hardware is designed to enable new workflows for music makers. Part of the intention of the hardware product is to allow a music maker to stay in the creative flow, without needing to turn to a different interface on a computer. The hardware needs to be able to show the user everything they need to see, in order to make music, from detailed waveforms to browsing for samples.
The interaction between the Push hardware and Live is a little complicated, so let’s start with a diagram:
Push communicates with the computer via two protocols over a USB interface, one of which is standard MIDI. This is a bidirectional protocol. Live uses it to control the pad colors and button lights on the hardware. When the user presses a button or a pad, a signal is sent over the MIDI channel back to Live. The other protocol communicating over USB allows sending image data to the hardware display. This means Push doesn’t need a processor running a more complex operating system and application to show GUI elements on the screen. The processor on the Push hardware is optimized solely for handling user input from the pads and buttons. So although Qt is used as the display technology on Push, it is not actually running on the device. When Live and Push are used together, Live starts another process which is responsible for rendering all of the content shown on the Push screen.
This architecture forces a strong implementation of the Model-View-ViewModel pattern. MVVM emphasises division of the lowest level of the data representation, the Model, from the representation which is intended to appear in a View, that is ‘the model of the view’, aka the ViewModel. Using QObjects with signalling functionality for the ViewModel, and using the same system for the View in QML, gives a high level of compatibility between the components of the design.
The Data Model – the values of parameters, and the content of a song – of what is shown on Push is defined in the Live 9.5 process and then shared via an IPC channel with the Push display process using a JSON protocol. The Push display process creates a ViewModel – QObjects with properties representing what should be shown on screen – making it available in the context of a QML engine, which
then defines the View for the Push screen. The rendered pixels are transformed to the pixel format expected by the hardware and then transferred over USB to Push.
On Push
What were the biggest benefits of using Qt for Push?
We evaluated several GUI technologies when starting work on Push, such as HTML and JUCE. Qt stands out mainly for the QML language, the QtQuick technology, the Scene Graph API and easy integration with OpenGL.
The obvious advantages of the QML language for rapid prototyping have really stood out for us, as well as the ability to extend it with plugins written in C++. Qt contains a broad range of ready-to-use APIs which we wouldn’t have access to if we had written the UI in HTML, for example. We try to make sure we make full use of all Qt/QML functionality that is appropriate for us, and keep an eye on new releases to see what becomes available.
How did the team take the new tools? How was the learning curve?
Initially a small task force investigated the GUI technologies available and when Qt was selected for Push, that task force began sharing their knowledge with the rest of the team. From that point, we have heavily relied on the invaluable Qt documentation.
The Qt blog is also an important resource, because articles there often display a more philosophical approach to how to write QML. While the Qt Forum or Stack Overflow can be a useful resource for QML beginners on how to get specific things done with available APIs, they often don’t provide principles and details about the mindset required to write and design declaratively with QML.
Writing QML code as a beginner is relatively easy. Trying things is cheap and easy and it results in very fast feedback because of the interpreted nature of the language. However, figuring things out as we go does not always lead to the best design. So a more interesting topic is ‘how difficult is it to do QML right as a beginner?’.
There are certain traps that we found, such as over-use of procedural code like onFooChanged to try to enforce a particular order of operations. It is better to encapsulate tolerance of indeterminate order of operations in a declarative interface, but learning the details of exactly how to do that and how to recognise the traps before we fall into them (or create new ones) is something that comes only with experience in the real world!
Developers new to QML need to learn a different approach to programming which is declarative instead of imperative, and where things can change ‘spontaneously’ or in an unexpected order. As we grow the team working on Push here at Ableton, new developers might leave QML to others because of caution about ‘doing it right’, or worrying that ‘there must be a better way’.
We are extending our best practices on how to write QML code and how to interface it with non-Qt code as time goes on, so we have accumulated some good guidelines now.
Were there technical challenges in getting the remote screen to work properly?
The technical separation of the user interface from the screen requires that we implement an unusually rigorous MVC pattern. The screen is really just a View and it doesn’t have any way to offer user interaction. There is no way to take convenient shortcuts on the hardware directly in response to a user interaction.
That separation means there are no GUI events handled in QML at all such as mouse, keyboard, push of a button or press of a pad. The View for Push is simply a declarative response to ViewModel updates received from Live, so changes are represented as ‘this is now the selected track’ rather than ‘this track was just clicked’.
However, user interaction hints do sometimes need to be part of the communication with the display process. For example, a single long list of items is broken up into a multi-column list. Changes of the ‘currently highlighted item’ are animated vertically through the adjacent column when the user scrolls.
The user can also use directional buttons on the hardware to change selection horizontally, and that calls for horizontal animation. So, it is not enough to update the ViewModel with the information that the selected item is now ‘My Heart Will Go On’. The information about whether that is the result of horizontal or vertical movement must also be conveyed in the protocol.
How about timing? Music making is real time, how does it all fit together?
The parts of Live that concern playback of music run in a separate thread to the UI, so that operations that can stall the Live UI, such as loading a large drum rack, do not stall the sound playback.
The process separation for the Push display process is an extension of this isolation from expensive operations in Live, in a sense. If Live is stalled in an expensive operation, the Push display process remains responsive. It is not possible to have multiple independent GUI threads with Qt, so the multi-process solution is the next best thing. We did, in an early iteration, attempt to combine the event loop used in Live with the Qt event loop. Qt APIs made the integration possible, but it seemed impossible to achieve our 60 fps target for the Push GUI while the Live GUI shared the same 16 ms time slices.
In fact, there is another level of separation in the architecture for real-time GUI updates. The IPC mechanism described previously is used only for updates to the song definition and user interface events. Real-time information such as the playhead progress uses a separate channel between the Live engine thread and the Push display process, so it even bypasses the Live GUI thread entirely. This
channel contains much lower traffic and so the display on Push for the playhead more accurately reflects real-time information.
Did you find any other benefits of QML when creating the Push interface?
One of the impressive things about QML is how animations work and how easy they are to use. There is something slightly magical about them. They’re so smooth and easy to add that we are not afraid of adding them – our designers sometimes have to restrain us!
Because our QML doesn’t deal with user input events, the View is often heavier than it needs to be. Reusable generic widgets, such as Button, usually implement some form of mouse and keyboard handling which we don’t need. Using primitives such as Rectangles may be an option to avoid the weight of Button features that are not used, but there are extra features in Button which we do use, such as text that fades out towards the edge and consistent styling. Additionally, we want to reuse code as far as possible. These concerns make it worthwhile to use the Button instead of a simpler alternative.
Any future plans on Push that you can share?
We are always looking for opportunities to develop our products, but I’m afraid we can’t give information about future plans. As any product developer knows: things can change!
Thank you for sharing your experiences with Qt and QML on the Push. It really is an amazing piece of music hardware.
Thank you! We are very proud of Push and what it enables musicians to create. Thank you too, for taking the time to conduct this interview.
Qt champions are the people that make the community a better place, the ones that enable you to build your world with Qt. They can be developers, people who help out on the forum, make videos or fix the documentation for everyone.
Take a moment to reflect who has been doing something special this year and go nominate them!
Like last year there are several categories for Qt Champions. The title is for one year, so go and nominate your Qt Champions!
Over a hundred Qt contributors gathered right next door to The Qt Company offices to talk about the current state and future of Qt.
The Friday pre-event drew a good crowd, who met up at The Qt Company offices. As the weather was nice, we went out for a picnic in the nearby park. This set the feeling of Qt Contributors’ Summit well, as it is a gathering of a community
The program for the weekend contains the session notes. The topics ranged from the upcoming QtCreator UI style changes to long term support in Qt. Every session drew an active crowd and there were many discussions. Between every session there was time to talk in the hallways, a very important part of a good Qt Contributors’ Summit.
For those of you who were taking notes in sessions, if you haven’t yet, please go and update the notes for the session on the wiki. Also for at least the more technical sessions, please post the notes to the Development mailing list, so as to make sure people who need to see the notes really do see them.
Memorable things from this years summit include the strong attendance from Japan, three community members present. We also had three of the current four Qt Champions present at the same time!
The Saturday evening event was held together with The Qt Company and local old trolls. The venue had a nice sunny balcony, and people enjoyed themselves after a long day of sessions.
I want to thank everyone who made this Qt Contributors’ Summit a great event. Our sponsors; The Qt Company, Intel, Boundary Devices, ICS, Froglogic,KDAB, e-Gits and Pelagicore. And Aliz and Anca from The Qt Company offices were an invaluable help in the event practicalities.
But most of all, thank you to everyone who attended.
Hope to see you all in Berlin at the Qt World Summit!
The first ever Wiki Week on the Qt Wiki is now over, and we did over 600 edits during it. 20 new pages were created and even more moved to the ‘delete’ category.
Overall the Qt Wiki is in a good shape, but there are things that needed fixing. The structure needed some updating, and still does. It was worked on, and to me the front page looks cleaner now.
The type of content we have in the Qt Wiki varies from code examples to official release team announcements, so keeping all the information in line requires some thinking and work. Especially with the history we have, after all Qt just turned 20! Having old code examples in the wiki isn’t good practice, and we need to make sure that old code is marked with the proper Qt version.
Our visiting statistics show that people come to the wiki looking for official information like release dates and QtCreator guidance. These are areas that we need to keep clearly visible and easy to find. The main page changes moved release information to a more prominent status, which should help our visitors find what they are looking for.
There was a discussion on the way the Qt Wiki is translated, where I promised to take a look whether the way Wikipedia does their translations would work for us. The Qt Wiki does not provide automatic translations to multiple languages, but we do have a lot of HowTo-articles that users have translated to local languages, making those easy to find from the main structure is important.
During the week one user was above everyone else in edits, Wieland spent a lot of time cleaning the language versions of the Wiki. A big thank you for that!
Also JKSH, Julienw and SGaist were active during the week. A thank you to them as well, and everyone else who worked on the wiki during last week!
To me the Wiki Week was a success that we should do more often. Maybe twice a year would be good, so it would be in line with the Qt release cycle.
This week is Wiki Week, the time to clean up the wiki.
The Wiki Week wiki page has a list of things to get started with. Cleaning up much viewed pages is a good place to start.
If you have some other activities you think would benefit the Qt Wiki, please post them on the Wiki subforum on the Qt Forum.
I’ll be following the Wiki and the Forum, and you can find me as tekojo on the main Qt IRC channels (qt, qt-labs, qt-chat) on Freenode during the day (European time).
Let’s see how much we can get done on the wiki this week!
Mark your calendars for 18-22.5.2015, we will have a Wiki Week to clean up the Qt Wiki.
During wiki week we will work together on these topics:
Cleaning up active pages
Marking old pages as needing updates
Archiving or removing completely outdated pages
Other ideas are also welcome, anything to make the wiki better! If you have something in mind, please post a new thread on the forums to theWiki Discussionsarea.
I opened a page on the wiki for the Wiki Week, for lists of actively visited pages and links to the list of pages that need updating.
I will also post more information here on the blog as I update the wiki page.
This is a friendly reminder that the Qt Contributors’ Summit is coming soon. June is only a month and a half away and Spring is well on it’s way in Oslo.
We will be gathering in Oslo, starting with an unofficial pre-event on the 5th June and the Summit on the weekend of 6th – 7th. If you are coming, please register by the end of this month with the registration form.
For those of you not familiar with the Qt Contributors’ Summit, it is a two day event for people contributing to the Qt project in some way. We gather to discuss the current state and future of the project. Everyone who shares our passion for Qt is welcome.
The wiki pages for the event are now online too. For those of you coming, the Program page is especially important, as the event format is an unconference. This means that the attendees can, and should, reserve slots for discussions and presentations in the event.
I would also like to thank all the companies that are making the Summit possible: The Qt Company, Boundary Devices, Intel, ICS, e-Gits, Froglogic, Pelagicore and KDAB. Thank you for helping make Qt Contributors’ Summit special this year!
Push communicates with the computer via two protocols over a USB interface, one of which is standard MIDI. This is a bidirectional protocol. Live uses it to control the pad colors and button lights on the hardware. When the user presses a button or a pad, a signal is sent over the MIDI channel back to Live. The other protocol communicating over USB allows sending image data to the hardware display. This means Push doesn’t need a processor running a more complex operating system and application to show GUI elements on the screen. The processor on the Push hardware is optimized solely for handling user input from the pads and buttons. So although Qt is used as the display technology on Push, it is not actually running on the device. When Live and Push are used together, Live starts another process which is responsible for rendering all of the content shown on the Push screen.
Memorable things from this years summit include the strong attendance from Japan, three community members present. We also had three of the current four Qt Champions present at the same time!
I want to thank everyone who made this Qt Contributors’ Summit a great event. Our sponsors; The Qt Company, Intel, Boundary Devices, ICS, Froglogic,KDAB, e-Gits and Pelagicore. And Aliz and Anca from The Qt Company offices were an invaluable help in the event practicalities.