Qt Contributor Summit 2023 - Program: Difference between revisions

From Qt Wiki
Jump to navigation Jump to search
No edit summary
No edit summary
 
Line 125: Line 125:
|[[Qt Quick Effect Maker - Basics and advanced usage]]
|[[Qt Quick Effect Maker - Basics and advanced usage]]
|[[Improving/extending QML type system]]
|[[Improving/extending QML type system]]
|[[Build system improvements and feedback|Build system news and feedback]]
|[[Two-way BC in Patch Releases]]
|[[Two-way BC in Patch Releases]]
|[[Build system improvements and feedback]]
|-
|-
|15:00 - 15:30
|15:00 - 15:30
Line 355: Line 355:
|
|
|-
|-
|Build system improvements and feedback
|Build system news and feedback
|Alexandru Croitor
|Alexandru Croitor
|Short presentation + discussion
|Short presentation + discussion

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
  • Roadmap and state of the Qt Project
  • Getting more external contributors, and increasing participation in the project
  • Pitching of afternoon sessions
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
  • Qt & Cyber Security
  • 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
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.


Let's discuss how we can evolve QIcon, QIconEngine, and the theming infrastructure we have, so that we can give application developers access to the platform's capabilities, and perhaps emulate what we can on other platforms.

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.

}

I18n with CMake Jörg Bornemann Presentation/Discussion 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.
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
Proposing a new module: Qt Local Authentication Lukas Kosiński Short presentation + Discussion 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.
Contributing to Qt Framework as a Consulting Company Lukas Kosiński Presentation 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.

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.

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++.
QML: Separate Language or Just a C++ Frontend? Przemysław Nogaj Presentation + Discussion 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++
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.