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?)