Qt Contributors Summit 2021 - Program

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: What we can learn from the KDE contribution experience First contribution and initial setup Gerrit improvements, plugins, etc Creation of "good first issues" in JIRA ...and all the good ideas you probably have.	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