Qt Contributors Summit 2021 - Program
Jump to navigation
Jump to search
Back to Qt Contributors Summit 2021
All times are in Central European Summer Time (CEST)
Talk Proposals
Please add your proposals here before end of day June 16th:
(for proposals to the Akademy program, please submit your proposal at https://akademy.kde.org/2021/cfp by the end of May 2nd)
| Topic | Who proposed | Description/Abstract | Preferred timeslot (optional) |
|---|---|---|---|
| Local testing on multiple platforms | Volker Hilsheimer (volker.hilsheimer@qt.io) | Our CI system Coin makes sure that changes are merged only once they build and pass test runs on all platforms we care about, but for developing cross platform code, nothing beats being able to build, run, and debug your local code before you push your changes to gerrit. In The Qt Company, an increasing number of developers are using minicoin, a vagrant-based system for managing and interacting with virtual machines. As its primary developer I'd like to see how we can make it useful for contributors as well! | any |
| Should Qt have plugin-based I/O? (like KIO but better) | Shawn Rutledge (shawn.rutledge@qt.io) | QML and Qt Quick have some ad-hoc QNetworkRequest code for fetching qml files and image files from web servers, but it seems a bit short-sighted that this is not done on top of some abstraction for reading files from various kinds of sources. (PDF files are rendered via Image, with this being one reason: to reuse that code rather that duplicating it. QTextDocument should support network loading too: that way it will become possible to load QML Text from a URL, or in widget apps with QTextBrowser, etc.) Http will not always be enough: the distributed web is an up-and-coming concept, and there have always been other protocols for fetching files and assets. Maybe we want to allow loading remote assets in QtQuick3D too, etc. Currently KIO is nicely extensible, but it's not built-in to Qt, and the architecture that requires a separate process for each operation is not ideal. What should we do about it? Another aspect of this is that we should probably have an I/O API in QML eventually; and it should probably follow good asynchronous design principles, and look familiar to Javascript developers. Hopefully it could be built upon the same I/O layer. Therefore we should design the new abstraction to be suitable for that. | overflow time should be available (end of the day then?) |
| Improve the contributor experience of the Qt project 🎉 (Take II) | Cristián Maureira-Fredes (cristian.maureira-fredes@qt.io) | Back in 2019 we had the discussion around the contribution experience, from which we gather many good ideas: some of them were never addressed, but others have been implemented, like for example the Qt project website and the Community Manager position that was open.
This session will try to address many of the open topics we had from that session looking at "What we could do" to keep improving the experience in topics like:
|
any |
| Passing small objects by value | Volker Hilsheimer (volker.hilsheimer@qt.io) | Most of our existing APIs pass even small types (such as QPoint(F), QRect, QSize) by reference, in spite of Thiago's analysis suggesting that those types should be passed by value to avoid memory access. Peppe has started to hand -1's out when reviewing code that introduces new code that passes those by reference. This goal of this session is to get us all on the same page, agree on what this means for our coding standards and tooling that supports that, and conclude whether it's worth and possible to do something about the existing code base. | any |
| Wanna help handling oss-fuzz issues? | Robert Löhning (robert.loehning@qt.io) | oss-fuzz is fuzzing Qt since the beginning of 2020. While a number of people contributed to this in various ways (Thank you!), I still seem to be the bottle-neck when it comes to forwarding oss-fuzz' reports to the Qt project as well as documenting affected and fixed versions of Qt. After a brief introduction to oss-fuzz in general, in this talk I'd like to demo what are the required steps. My hope is, that some people will be interested in joining me, so we could share the work, extend the coverage and thus make Qt more secure and reliable. | any |
| Wayland client BOF | Eskil Abrahamsen Blomfeldt (eskil.abrahamsen-blomfeldt@qt.io) | Synchronization on topics concerning the Wayland client plugin with Qt, KDE and others. | any |
| Qt Buildsystem Feedback | Alexandru Croitor (alexandru.croitor@qt.io) | Qt 6 switched to using CMake for building Qt. The session is meant to gather feedback / pain points about building Qt as well as using Qt in a user project (from a build system perspective). General questions about build system usage are also welcome. | any |
| CMake API for QML modules | Ulf Hermann
(ulf.hermann@qt.io) |
Let's talk about how we're supposed to write QML modules in Qt 6.2+. It differs quite a bit from what you're used to. | any |
| Testing upstream changes with downstream modules | Mitch Curtis
(mitch.curtis@qt.io) |
A discussion to find the best solution to the issue of changes in one module (upstream) not being tested with modules (downstream) that depend on that module. | any |
| Changes to Qt WebEngine API and development in Qt 6 | Allan Sandfeld Jensen
(allan.jensen@qt.io) |
An update and discussion on changes in Qt WebEngine API in Qt 6, and where we are moving from here. | any |
| Wayland text-input-unstable-v4 protocol | Eskil Abrahamsen Blomfeldt
(eskil.abrahamsen-blomfeldt@qt.io) |
The next iteration of the text-input protocol is currently in specification phase. Qt is lacking in this area, and we should collaborate with the upstream project to make sure we get it right. This is a session to discuss the protocol and get everyone on the same page. | any |
Tuesday, 2021-06-22
| Topic | Who proposed | Description/Abstract | Preferred timeslot (optional) |
|---|---|---|---|
| Qt for Python | Friedemann Kleint (Friedemann.Kleint@qt.io) | Let's talk about what can be improved in Qt for Python and how you can contribute | any |