Qt Contributor Summit 2023 - Program: Difference between revisions
(Adding QtWayland Remaining Issues to the Programme) |
No edit summary |
||
(32 intermediate revisions by 13 users not shown) | |||
Line 14: | Line 14: | ||
|- | |- | ||
|08:30 - 09:30 | |08:30 - 09:30 | ||
| colspan="4" |''Registration + Coffee | | colspan="4" |''Registration + Welcome Coffee'' | ||
|- | |- | ||
|09:30 - 12:00 | |09:30 - 12:00 | ||
| colspan="4" |'''Keynote Session 1''' | | colspan="4" |'''Keynote Session 1''' | ||
* Roadmap and state of the Qt Project | |||
Roadmap and state of the Qt Project | * Getting more external contributors, and increasing participation in the project | ||
* Pitching of afternoon sessions | |||
Getting more external contributors, and increasing participation in the project | |||
|- | |- | ||
!style="background-color:#41cd52" |Time (CEST) | !style="background-color:#41cd52" |Time (CEST) | ||
Line 33: | Line 32: | ||
|- | |- | ||
|13:00 - 13:30 | |13:00 - 13:30 | ||
|TaskTree | |[[TaskTree CS23]] | ||
|Qt - Connected First | |[[Qt - Connected First]] | ||
| | | | ||
| | | | ||
|- | |- | ||
| 13:30 - 14:00 | | 13:30 - 14:00 | ||
|moc in 202x and beyond | |[[moc in 202x and beyond]] | ||
|RESTful Qt clients | |[[RESTful Qt clients]] | ||
|QtGraphs API and architecture | |[[QtGraphs API and architecture]] | ||
| | | | ||
|- | |- | ||
|14:00 - 14:30 | |14:00 - 14:30 | ||
|Improve API review process | |[[Improve API review process]] | ||
| | |[[Qt Creator API]] | ||
|Qt Academy | |[[Qt Academy]] | ||
| | | | ||
|- | |- | ||
|14:30 - 15:00 | |14:30 - 15:00 | ||
|VScode plugin demo | |[[VScode plugin demo]] | ||
|Feature planning and better | | rowspan="2" |[[Feature planning and better involvement of external contributors]] | ||
involvement of | |||
external contributors | |||
| | | | ||
| | | | ||
|- | |- | ||
| 15:00 - 15:30 | | 15:00 - 15:30 | ||
|rowspan="2"| Evolving QIcon and theming | |rowspan="2"| [[Evolving QIcon and theming]] | ||
| | |[[Present and future of Qt for Python]] | ||
| | | | ||
|- | |- | ||
|15:30 - 16:00 | |15:30 - 16:00 | ||
| | |[[String Handling]] | ||
|Gerrit and CI plans | |[[Gerrit and CI plans]] | ||
| | | | ||
| | | | ||
|- | |- | ||
|16:00 - | |16:00 - 16:30 | ||
|colspan="4" |''Coffee Break'' | |colspan="4" |''Coffee Break'' | ||
|- | |- | ||
Line 88: | Line 84: | ||
|- | |- | ||
|08:30 - 09:30 | |08:30 - 09:30 | ||
| colspan="4" |''Coffee | | colspan="4" |''Welcome Coffee'' | ||
|- | |- | ||
|09:30 - 12:00 | |09:30 - 12:00 | ||
| colspan="4" |'''Keynote Session 2''' | | colspan="4" |'''Keynote Session 2''' | ||
Qt & Cyber Security | * Qt & Cyber Security | ||
* Modern C++ | |||
Modern C++ | ** Qt in Programming: Principles and Practices using C++, 3rd edition | ||
** Qt and Senders/Receivers | |||
** State of C++20 in Qt | |||
* Pitching of afternoon sessions | |||
|- | |- | ||
!style="background-color:#41cd52" |Time (CEST) | !style="background-color:#41cd52" |Time (CEST) | ||
Line 110: | Line 105: | ||
|- | |- | ||
|13:00 - 13:30 | |13:00 - 13:30 | ||
| | |[[Qt & Cyber Security (Discussion)]] | ||
|QML: | |[[QML: General purpose language or frontend for QtQuick]] | ||
or | |[[QtWayland Remaining Issues]] | ||
| | |||
| | | | ||
|- | |- | ||
|13:30 - 14:00 | |13:30 - 14:00 | ||
|QSharedMemory & QSystemSemaphore in Qt 7 | |[[QSharedMemory & QSystemSemaphore in Qt 7]] | ||
|More languages in the Qt Project | |[[More languages in the Qt Project]] | ||
| | |[[Stable Qt Creator API - Wishlist creation]] | ||
| | | | ||
|- | |- | ||
|14:00 - 14:30 | |14:00 - 14:30 | ||
|From design to application as the new kid on the block | |[[From design to application as the new kid on the block]] | ||
| | |[[QMetaType and QVariant]] | ||
| | |[[Qt For WebAssembly]] | ||
| | | | ||
|- | |- | ||
|14:30 - 15:00 | |14:30 - 15:00 | ||
|Qt Quick Effect Maker - Basics and advanced usage | |[[Qt Quick Effect Maker - Basics and advanced usage]] | ||
| | |[[Improving/extending QML type system]] | ||
| | |[[Build system improvements and feedback|Build system news and feedback]] | ||
| | |[[Two-way BC in Patch Releases]] | ||
|- | |- | ||
|15:00 - | |15:00 - 15:30 | ||
|colspan="4" |''Coffee Break'' | |colspan="4" |''Coffee Break'' | ||
|- | |- | ||
Line 217: | Line 211: | ||
[[Category:QtCS2023]] | [[Category:QtCS2023]] | ||
|- | |- | ||
|I18n with CMake | |<s>I18n with CMake</s> | ||
| Jörg Bornemann | | <s>Jörg Bornemann</s> | ||
|Presentation/Discussion | |<s>Presentation/Discussion</s> | ||
|The existing CMake i18n commands are too limited for more complex projects. We'll present the overhauled i18n Qt/CMake commands that we want to release with Qt 6.7 and collect feedback from you. | |<s>The existing CMake i18n commands are too limited for more complex projects. We'll present the overhauled i18n Qt/CMake commands that we want to release with Qt 6.7 and collect feedback from you.</s> | ||
| | | | ||
|- | |- | ||
Line 260: | Line 254: | ||
| | | | ||
|- | |- | ||
|Proposing a new module: Qt Local Authentication | |<s>Proposing a new module: Qt Local Authentication</s> | ||
|Lukas Kosiński | |<s>Lukas Kosiński</s> | ||
|Short presentation + Discussion | |<s>Short presentation + Discussion</s> | ||
|We're introducing a proposal for a dedicated Qt module supporting native fingerprint and face recognition. This session will highlight the specific API elements we're suggesting and the key reasons driving this addition. Discussion will encompass potential challenges, and the practical advantages for Qt developers. We invite feedback to refine this vision, aiming to bolster Qt's capabilities in the realm of secure user authentication. | |<s>We're introducing a proposal for a dedicated Qt module supporting native fingerprint and face recognition. This session will highlight the specific API elements we're suggesting and the key reasons driving this addition. Discussion will encompass potential challenges, and the practical advantages for Qt developers. We invite feedback to refine this vision, aiming to bolster Qt's capabilities in the realm of secure user authentication.</s> | ||
| | | | ||
|- | |- | ||
|Contributing to Qt Framework as a Consulting Company | |<s>Contributing to Qt Framework as a Consulting Company</s> | ||
|Lukas Kosiński | |<s>Lukas Kosiński</s> | ||
|Presentation | |<s>Presentation</s> | ||
|The realm of open-source contributions is a journey filled with both challenges and rewards. As a consulting company deeply embedded in the Qt ecosystem, we've lately ventured into the intricate process of contributing to the Qt framework. In this discussion, we’ll unravel our experiences, detailing our motivations, the hurdles we encountered, and the triumphs we celebrated. | |<s>The realm of open-source contributions is a journey filled with both challenges and rewards. As a consulting company deeply embedded in the Qt ecosystem, we've lately ventured into the intricate process of contributing to the Qt framework. In this discussion, we’ll unravel our experiences, detailing our motivations, the hurdles we encountered, and the triumphs we celebrated.</s> | ||
My perspective will provide insights into the mindset and preparation needed when embarking on such contributions, especially for those treading this path for the first time. | <s>My perspective will provide insights into the mindset and preparation needed when embarking on such contributions, especially for those treading this path for the first time.</s> | ||
| | | | ||
|- | |- | ||
Line 286: | Line 280: | ||
| | | | ||
|- | |- | ||
|QML: Separate Language or Just a C++ Frontend? | |<s>QML: Separate Language or Just a C++ Frontend?</s> | ||
|Przemysław Nogaj | |<s>Przemysław Nogaj</s> | ||
|Presentation + Discussion | |<s>Presentation + Discussion</s> | ||
|In the rapidly evolving landscape of Qt development, the future of QML (Qt Meta-Object Language) and its relationship with C++ is a topic of paramount importance. Before we embark on discussions regarding Qt 7, it is crucial to pause and reflect on the unique features and capabilities of QML. Some language-level mechanisms, such as Attached Properties and Value Types, are only feasibly defined from the C++ level. Conversely, QML effortlessly accommodates concepts like optional properties and asynchronous function calls, facilitated through constructs like Promises. What if QML could transcend its C++ bindings and become technology-agnostic, enabling alternative languages like Dart or Java to interact seamlessly? Shall QML (detached from QtQuick) deliver kind of it's own standard library to provide essential functionalities like file access? To ignite our discussion, we will use a practical example: the mocking of C++ classes. This approach facilitates the effortless provision of resources to technical artists using Qt Design Studio. Our goal is to explore methods that make C++ classes accessible without the need for compiling or writing C++ code, effectively bridging the gap between QML's rapid prototyping capabilities and the robustness of C++ | |<s>In the rapidly evolving landscape of Qt development, the future of QML (Qt Meta-Object Language) and its relationship with C++ is a topic of paramount importance. Before we embark on discussions regarding Qt 7, it is crucial to pause and reflect on the unique features and capabilities of QML. Some language-level mechanisms, such as Attached Properties and Value Types, are only feasibly defined from the C++ level. Conversely, QML effortlessly accommodates concepts like optional properties and asynchronous function calls, facilitated through constructs like Promises. What if QML could transcend its C++ bindings and become technology-agnostic, enabling alternative languages like Dart or Java to interact seamlessly? Shall QML (detached from QtQuick) deliver kind of it's own standard library to provide essential functionalities like file access? To ignite our discussion, we will use a practical example: the mocking of C++ classes. This approach facilitates the effortless provision of resources to technical artists using Qt Design Studio. Our goal is to explore methods that make C++ classes accessible without the need for compiling or writing C++ code, effectively bridging the gap between QML's rapid prototyping capabilities and the robustness of C++</s> | ||
| | | | ||
|- | |- | ||
Line 322: | Line 316: | ||
|Discussion | |Discussion | ||
|It took many years from the initial development of PySide until it was officially part of the Qt Project, and many other years to be officially released. This added Python to the Qt Project language stack, but what about all the others? This discussion has the goal of gathering ideas on how the Qt Project can adopt more languages in the form of bindings, libraries, tools, packaging, or any other prototype. People with interest in Rust, Zig, and Carbon are welcomed, but if someone else has any other remarks regarding other comments, feel free to join and share your thoughts. | |It took many years from the initial development of PySide until it was officially part of the Qt Project, and many other years to be officially released. This added Python to the Qt Project language stack, but what about all the others? This discussion has the goal of gathering ideas on how the Qt Project can adopt more languages in the form of bindings, libraries, tools, packaging, or any other prototype. People with interest in Rust, Zig, and Carbon are welcomed, but if someone else has any other remarks regarding other comments, feel free to join and share your thoughts. | ||
| | | | ||
|- | |- | ||
Line 335: | Line 322: | ||
|Presentation + discussion | |Presentation + discussion | ||
|Presentation about planned improvements in Gerrit and CI area. Discussion about future needs and ideas. | |Presentation about planned improvements in Gerrit and CI area. Discussion about future needs and ideas. | ||
| | |||
|- | |||
|C++20 in Qt | |||
|Marc Mutz | |||
|Presentation + Discusssion | |||
|At QtWS last year, Marc gave an overview over what the advent of C++20 means for Qt development going forward. This session looks at what has been achieved since then and what remains to be done. | |||
| | |||
|- | |||
|Evolving Qt String Handling | |||
|Marc Mutz | |||
|Presentation + Discussion | |||
|Ever since Qt 2, QString is using UTF-16 encoding, but the world has evolved since then: UTF-8 has become a much more widely used encoding, but Qt has no type to represent it and lacks most algorithms for dealing with it. QByteArray doubles as a QUtf8String and an actual array-of-bytes, but its toUpper/toLower/CaseInsensitive functions use Latin-1 semantics. OTOH, UTF-8 has the nasty problem that it's variable-length, so comparing and searching are inefficient (no UTF-8 Boyer-Moore search for indexOf, no early length mismatch check for operator==), making it a bad choice as an in-memory format. Python strings, with which Qt now interacts intimately by way of PySide, are variant strings that hold L1, UTF-16 or UTF-32, depending on the actual content of the string, ensuring that the string does not contain multi-byte sequences or surrogate pairs. UTF-8 is only used for interfacing with C. Qt has no UTF-32 support at all atm. The presenter's goal is to make a QAnyString that's like Python strings (except that it also supports UTF-8), in that it preserves the original encoding, and then to have QLatin1String, QUtf8String, QUtf16String and QUtf32String for when you statically know what encoding you work on, plus the respective views. QByteArray should be just that: an array of std::byte, not a string-ish. There are several cornerstone pieces of the puzzle missing: QAnyString, QUtf8String (waiting for C++20 char8_t support) and QLatin1String (owner, waiting for Qt 7 to free up the name), and QByteArray losing it's string-ish API parts. With required C++20 support likely coming up after the next LTS (6.8), now's the time to settle on a common understanding of the goals and how to get there, so we can proceed with QUtf8String and QAnyString. | |||
| | | | ||
|- | |- | ||
Line 347: | Line 346: | ||
|Discussion | |Discussion | ||
|There's a lot of cruft in these two classes, from years of legacy. We should take a look to see what we understand (so we can dedicate time to what we don't), then see what can be removed / simplified, and what's next. | |There's a lot of cruft in these two classes, from years of legacy. We should take a look to see what we understand (so we can dedicate time to what we don't), then see what can be removed / simplified, and what's next. | ||
| | |||
|- | |||
|Qt for WebAssembly | |||
|Morten Sørvig | |||
|Discussion | |||
|WebAssembly is becoming more relevant, also outside of the context of the web platform. In this session we'll take a look at the current state of Qt-on-the-web and discuss future development plans. Topics include dynamic linking, WebGPU support, and overall better platform integration (font handling, local file access, drag-and-drop support, etc). | |||
If there is time and interest we'll also discuss non-web use cases such as WASI or wasm plugins for Qt. | |||
| | |||
|- | |||
|Build system news and feedback | |||
|Alexandru Croitor | |||
|Short presentation + discussion | |||
|Latest news regarding various build system improvements, plans, and a session to collect feedback on pain points. | |||
|` | |||
|- | |||
|QML: General purpose language or frontent for QtQuick | |||
|Ulf Hermann | |||
|discussion | |||
|I often encounter a sentiment to dismiss QML as simply some hack to make QtQuick happen. The proponents of such sentiment often transfer all the love or hate they may have towards QtQuick into QML. This has wide ranging implications, for example when trying to establish support API in QtCore or similar foundational libraries. Why do we have to expose metatypes.json files for libraries that don't tie into QtQuick after all? Why should we annotate our value types with Q_GADGET? Etc. | |||
| | | | ||
|} | |} |
Latest revision as of 12:00, 1 December 2023
Sessions
Please, add your sessions/talks/presentations to the table by the end of the page.
→ If you have any issues while editing this page, please contact Pedro Bessa directly at pedro.bessa@qt.io
Event main page: Qt Contributor Summit 2023
Thursday, Nov 30th | ||||
---|---|---|---|---|
Time (CEST) | Room A | |||
08:30 - 09:30 | Registration + Welcome Coffee | |||
09:30 - 12:00 | Keynote Session 1
| |||
Time (CEST) | Room A | Room B | Room C | Common area |
12:00 - 13:00 | Lunch break | |||
13:00 - 13:30 | TaskTree CS23 | Qt - Connected First | ||
13:30 - 14:00 | moc in 202x and beyond | RESTful Qt clients | QtGraphs API and architecture | |
14:00 - 14:30 | Improve API review process | Qt Creator API | Qt Academy | |
14:30 - 15:00 | VScode plugin demo | Feature planning and better involvement of external contributors | ||
15:00 - 15:30 | Evolving QIcon and theming | Present and future of Qt for Python | ||
15:30 - 16:00 | String Handling | Gerrit and CI plans | ||
16:00 - 16:30 | Coffee Break | |||
16:30 - 17:00 | Summary of Day 1 |
Friday, Dec 1st | ||||
---|---|---|---|---|
Time (CEST) | Room A | |||
08:30 - 09:30 | Welcome Coffee | |||
09:30 - 12:00 | Keynote Session 2
| |||
Time (CEST) | Room A | Room B | Room C | Common Area |
12:00 - 13:00 | Lunch break | |||
13:00 - 13:30 | Qt & Cyber Security (Discussion) | QML: General purpose language or frontend for QtQuick | QtWayland Remaining Issues | |
13:30 - 14:00 | QSharedMemory & QSystemSemaphore in Qt 7 | More languages in the Qt Project | Stable Qt Creator API - Wishlist creation | |
14:00 - 14:30 | From design to application as the new kid on the block | QMetaType and QVariant | Qt For WebAssembly | |
14:30 - 15:00 | Qt Quick Effect Maker - Basics and advanced usage | Improving/extending QML type system | Build system news and feedback | Two-way BC in Patch Releases |
15:00 - 15:30 | Coffee Break | |||
15:30 - 16:30 | Summary of Day 2 |
It doesn't need to be a final version of what will be presented, but it's good to have an idea of the presentation's scope and general lines.
Topic | Speaker | Format | Summary | |
---|---|---|---|---|
TaskTree | Jarek Kobus | Presentation | TaskTree - generic solution for automatic management of asynchronous task (C++). More info: https://wiki.qt.io/TaskTree.
The TaskTree can automatically manage the chain (or tree) of asynchronous tasks of mixed types. The recipe on how to run and manage the conglomerate of tasks is described in a declarative way in C++. The recipes are enclosed in copyable value-type objects and may be run many times, or be part of more general recipes. The TaskTree is currently broadly used in QtCreator, e.g. for executing Build / Deploy configurations, Locator filter, Clang tool, Autotests, and much more... The TaskTree's implementation is separated from the QtCreator specific code and may already serve as a general purpose solution outside of QtCreator. | |
Qt - Connected First | Vladimir Minenko | Discussion (with some presentations) | Since a while there are multiple additions to Qt which target more efficient development of apps when talking to different web services as well as implementing distributed architectures. As of July 2023, it ranges from the new Qt gRPC module and the "revived" Qt HTTP Server to ongoing works on various helpers for REST in Qt (see QTBUG-112276 and issues linked to it). Not mentioning the Qt Interface Framework and Qt D-Bus as IPC components in Qt.
But what should we do next or differently in this domain? Introduce an integration of GraphQL? Invest more time in OpenAPI instead of GraphQL? In this session, we will give an overview of what is going on and awhat isa vailable, but most importantl ,we want to discuss and hear your views and opinion.s . | |
Evolving QIcon and theming | Volker Hilsheimer | Discussion | QIcon delegates the loading and rendering of icons to platform-specific icon engines, ultimately producing a pixmap. Theme support is very much based on the freedesktop spec, which hasn't moved much since 2006 years. In more recent years, Microsoft and esp Apple have added rich support for icons to their platforms.
QIcon and the theme-abstraction as it is today doesn't map well to those capabilities. The implementation has improved in the context of QTBUG-102346, but the design is in general too limited to support multiple system themes, layered icons with variable properties, and icon coloring and tinting with palette or hierarchical color support.
Since it's related, we might also talk about QtSvg, support for vector graphics animations and animated emojis. | |
QtWayland Remaining Issues | David Edmundson | Discussion | The Wayland API does not map nicely to patterns used on every other platform in various aspects of window management. We need to fix popups, find a direction for the native API and look at what other unsolved issues we have in the QPA that we either need to fix here or upstream. | |
Getting more external contributors | David Edmundson | Presentation | Having the QtProject developed by a wide range of developers is an important part of getting the most of being an open source project. There's a lot of really simple things we can all do as developers to both attract new developers and build them into future maintainers. I can present some experiences from contributing to many other open source projects of what works well from both the contributor and maintainer point of view. | |
Qt & Cyber Security | Kai Köhne | Discussion | Interest in cyber security topics has vastly increased in the last months. A lot of customers are asking how 'secure' Qt is ... which is sometimes hard to answer, also given that Qt is a framework, and can be used in countless (and sometimes surprising) ways. How can we improve our security practices themselves, and how can we communicate 'best practices' how to use Qt to our users? | |
Two-way BC in Patch Releases | Volker Hilsheimer | Discussion | We currently promise to maintain both forward and backwards binary compatibility within a patch cycle. While backwards BC is not controversial, forward compatibility seems to have no practical purpose for our users. Qt developer can test issues against several patch levels of the same release without recompiling, but that's such a minor benefit that it might not justify the restrictions forward BC impose on us. Conclusion of discussion on https://lists.qt-project.org/pipermail/development/2023-August/044333.html | |
Improve API review process | Alex Blasche | Discussion | Our API reviews for Qt 6.5 & 6.6 were significantly longer than previous releases. Partly this was caused by more issues being found, reviews being more thorough and potentially because there very slow response and action after review comments are done. Let's discuss how we can improve the situation. |
} |
QtGraphs API and architecture | Tomi Korpipää, Kwanghyo Park | Workshop/Discussion | The architecture in QtGraphs in Qt 6.6, apart from replacing the 3D rendering engine and some of the plumbing, is basically a carbon copy of QtDataVisualization, which was originally made over 10 years ago. We have already implemented some architecture and API changes for Qt 6.7, but there is more to be done. How can we modernize the API and architecture further? | |
moc in 202x and beyond | Fabian Kosmale | Workshop/Discussion | moc is a central part of Qt's meta-object system. It's also a glorified pre-processor, and it's getting long in the tooth: We still don't support some C++11 constructs, let alone C++20 modules. There have been previous approaches towards replacing moc: e.g. Olivier's moc-ng (https://github.com/woboq/moc-ng) as an alternative implementation, and Verdigris as a pure macro-based implementation. There was also a hope that C++ itself would gain sufficient reflection facilities, but that is unlikely to happen in the near future. In this session, I'd like to evaluate the requirements we have for moc inside Qt, and discuss a way forward for it. | |
Improving/extending the QML typesystem | Fabian Kosmale, QML team | Discussion | There has been a desire to support std::optional in QML (see e.g. "std::optional for Q_PROPERTY"). Moreover, we have many properties in Qt Quick and Controls which use "var" as their type, but which could be modeled with closed sum types (std::variant in C++). Moreover, we have some properties of type var which take functions/callbacks, e.g. TableView's columnWidthProvider. In this session, we'd like to discuss both use cases, as well as details on how that could be integrated with Qt's metatype system. | |
Feature planning and better involvement of external contributors | Vladimir Minenko, Alex Blasche | Discussion | Explore options for how external (not employed by The Qt Company) contributors could join grooming/planning sessions for their areas of interest. Vladimir recently started this effort in the context of Qt Network, but other domains like QtCore may benefit from it too. | |
Creating courses with Qt Academy | Emilia Valkonen-Damjanovic, Ashley Walton | Presentation/Discussion | Showcasing Qt Academy and discussing the pillars of engaging online learning for those who want to contribute to the platform. | |
Present and future of Qt for Python | Friedemann, Shyam, Adrian, and Cristián | Short presentation + Discussion | The project has been adding many features "on top of Qt" and we are currently well position in the Python ecosystem, but the sky is the limit so we need more feedback from users and new ideas that can help our Python offering to grow more. Complementary, we invite C++ developers to share their thoughts on the current available Qt modules, and which Python functionality they would love to have in their C++ projects. https://doc.qt.io/qtforpython | |
|
||||
Qt and Senders/Receivers (and coroutines) | Ville Voutilainen | Presentation | There is an implementation for adapting QThreads as P2300 schedulers, and QObject signals as P2300 senders (see https://wg21.link/p2300). This gives Qt generic support for C++20 coroutines, among other things. The presentation shows how this works. | |
Qt in Programming: Principles and Practices using C++, 3rd edition | Ville Voutilainen | Presentation | Bjarne Stroustrup's new textbook will feature a Qt-based support library for the book's Graph/GUI chapters. The presentation will explain how we got there, what the support library does, and how it's to be used in university courses teaching C++. | |
RESTful Qt clients | Juha Vuolle | Presentation + discussion | A brief overview into current ways of developing 'traditional' HTTP RESTful Qt client applications, and then look into the nearby and mid-term future plans and initiatives in that front. | |
From design to application as the new kid on the block | Sakaria Pouke | Presentation | How well does Design Studio fare in the hands of a new software engineer? As QtGraphs is close to succeeding the Data Visualization module, some of its examples will also need an upgrade. Such is the case with the StocQt example app, designed to showcase stock market data. This talk will walk through the design and implementation of a new look for StocQT and provide an example of how newcomers may approach designing and implementing an application using Figma, Qt Design Studio and Qt Creator. | |
Qt Quick Effect Maker - Basics and advanced usage | Kaj Grönholm | Presentation | Qt Quick Effect Maker (QQEM) is a custom shader effect tool first introduced in Qt 6.5. In this presentation going first through basics of the tool UI and the usage. Then showing how to port an effect from Shadertoy into QQEM and exporting into your Qt Quick application. Finally presenting some examples where QQEM has already been used. | |
Qt integration within Visual Studio Code IDE | Serg Kryvonos | New Prototype Demo + Gathering Feature Requests Session | The Qt Company introduces new plugin for famous open-source Visual Studio Code IDE.
Demo includes new functional prototype of integrating Qt with existing CMake plugin which is intended to simplify work of C++ developers who actively use Qt Framework in their projects. Preceded by small presentation with an overview of other features for new plugin, feedback and features request session officially opens this new community dialog right after the demo. |
|
More languages in the Qt Project | Cristián Maureira-Fredes | Discussion | It took many years from the initial development of PySide until it was officially part of the Qt Project, and many other years to be officially released. This added Python to the Qt Project language stack, but what about all the others? This discussion has the goal of gathering ideas on how the Qt Project can adopt more languages in the form of bindings, libraries, tools, packaging, or any other prototype. People with interest in Rust, Zig, and Carbon are welcomed, but if someone else has any other remarks regarding other comments, feel free to join and share your thoughts. | |
Gerrit and CI plans | Jukka Jokiniva | Presentation + discussion | Presentation about planned improvements in Gerrit and CI area. Discussion about future needs and ideas. | |
C++20 in Qt | Marc Mutz | Presentation + Discusssion | At QtWS last year, Marc gave an overview over what the advent of C++20 means for Qt development going forward. This session looks at what has been achieved since then and what remains to be done. | |
Evolving Qt String Handling | Marc Mutz | Presentation + Discussion | Ever since Qt 2, QString is using UTF-16 encoding, but the world has evolved since then: UTF-8 has become a much more widely used encoding, but Qt has no type to represent it and lacks most algorithms for dealing with it. QByteArray doubles as a QUtf8String and an actual array-of-bytes, but its toUpper/toLower/CaseInsensitive functions use Latin-1 semantics. OTOH, UTF-8 has the nasty problem that it's variable-length, so comparing and searching are inefficient (no UTF-8 Boyer-Moore search for indexOf, no early length mismatch check for operator==), making it a bad choice as an in-memory format. Python strings, with which Qt now interacts intimately by way of PySide, are variant strings that hold L1, UTF-16 or UTF-32, depending on the actual content of the string, ensuring that the string does not contain multi-byte sequences or surrogate pairs. UTF-8 is only used for interfacing with C. Qt has no UTF-32 support at all atm. The presenter's goal is to make a QAnyString that's like Python strings (except that it also supports UTF-8), in that it preserves the original encoding, and then to have QLatin1String, QUtf8String, QUtf16String and QUtf32String for when you statically know what encoding you work on, plus the respective views. QByteArray should be just that: an array of std::byte, not a string-ish. There are several cornerstone pieces of the puzzle missing: QAnyString, QUtf8String (waiting for C++20 char8_t support) and QLatin1String (owner, waiting for Qt 7 to free up the name), and QByteArray losing it's string-ish API parts. With required C++20 support likely coming up after the next LTS (6.8), now's the time to settle on a common understanding of the goals and how to get there, so we can proceed with QUtf8String and QAnyString. | |
QSharedMemory and QSystemSemaphore in Qt 7 | Thiago Macieira | Discussion | See https://lists.qt-project.org/pipermail/development/2023-November/044680.html | |
QMetaType and QVariant | Thiago Macieira | Discussion | There's a lot of cruft in these two classes, from years of legacy. We should take a look to see what we understand (so we can dedicate time to what we don't), then see what can be removed / simplified, and what's next. | |
Qt for WebAssembly | Morten Sørvig | Discussion | WebAssembly is becoming more relevant, also outside of the context of the web platform. In this session we'll take a look at the current state of Qt-on-the-web and discuss future development plans. Topics include dynamic linking, WebGPU support, and overall better platform integration (font handling, local file access, drag-and-drop support, etc).
If there is time and interest we'll also discuss non-web use cases such as WASI or wasm plugins for Qt. |
|
Build system news and feedback | Alexandru Croitor | Short presentation + discussion | Latest news regarding various build system improvements, plans, and a session to collect feedback on pain points. | ` |
QML: General purpose language or frontent for QtQuick | Ulf Hermann | discussion | I often encounter a sentiment to dismiss QML as simply some hack to make QtQuick happen. The proponents of such sentiment often transfer all the love or hate they may have towards QtQuick into QML. This has wide ranging implications, for example when trying to establish support API in QtCore or similar foundational libraries. Why do we have to expose metatypes.json files for libraries that don't tie into QtQuick after all? Why should we annotate our value types with Q_GADGET? Etc. |