Qt Contributors Summit 2021 - Program: Difference between revisions
Jump to navigation
Jump to search
(→Talk Proposals: plugin-based I/O, and QML API for that) |
mNo edit summary |
||
| Line 17: | Line 17: | ||
|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 [https://git.qt.io/vohilshe/minicoin/-/wikis/home 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 | |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 [https://git.qt.io/vohilshe/minicoin/-/wikis/home 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. Http will not always be enough: the distributed web is an up-and-coming concept, and there | |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?) | ||
|} | |} | ||
Revision as of 10:18, 5 May 2021
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?) |