Qt Contributors Summit 2019 Program: Difference between revisions

From Qt Wiki
Jump to navigation Jump to search
(I still take requests)
 
(53 intermediate revisions by 22 users not shown)
Line 87: Line 87:
|  
|  
| [[Qt Contributors Summit 2019 Program#Improve the contributor experience of the Qt project|Improve the contributor experience of the Qt project]]
| [[Qt Contributors Summit 2019 Program#Improve the contributor experience of the Qt project|Improve the contributor experience of the Qt project]]
|[[Qt Contributors Summit 2019 Program#Qt 6 Migration strategy|Qt 6 Migration strategy]] + Source (in)compatible changes in Qt 6
|[[Qt Contributors Summit 2019 Qt 6 Changes / Migration|Qt 6 Changes / Migration]]
|-
|-
|12:20 - 13:20
|12:20 - 13:20
Line 94: Line 94:
|13:20 - 14:00
|13:20 - 14:00
| rowspan="2" |[[Qt Contributors Summit 2019 Program#C.2B.2B17 language and std library features for Qt 6|C++17 language and std library features for Qt 6]]
| rowspan="2" |[[Qt Contributors Summit 2019 Program#C.2B.2B17 language and std library features for Qt 6|C++17 language and std library features for Qt 6]]
|[[Qt Contributors Summit 2019 Program#Qt Wayland Client and extensions|Qt Wayland Client and extensions]]
|
|Entry points in Qt (Android, iOS, Win32)
|[[Qt application lifecycle (startup, shutdown, sessions)]]
| rowspan="2" |[[Qt Contributors Summit 2019 Program#Releasing|Releasing]]
| rowspan="2" |[[Qt Contributors Summit 2019 Program#Releasing|Releasing]]
|-
|-
|14:10 - 14:50
|14:10 - 14:50
|QtGUI, RHI & 3D
|[[Qt Contributors Summit 2019 Program#QtGui RHI 3D|QtGui, RHI & 3D]]
|  
|  
|-
|-
Line 107: Line 107:
|15:10 - 15:50
|15:10 - 15:50
|[[Qt Contributors Summit 2019 Program#Fuzzing Qt|BoF: Fuzzing Qt]]
|[[Qt Contributors Summit 2019 Program#Fuzzing Qt|BoF: Fuzzing Qt]]
|[[Qt Contributors Summit 2019 Program#Branch policy for Qt 6|Branching policy]]
|[[Qt Contributors Summit 2019 Program#Branch Policy for Qt 6|Branching policy]]
| [[Rethinking serialization for Qt6]]
| [[Rethinking serialization for Qt6]]
|[[Qt Contributors Summit 2019 Program#High DPI|High DPI]]
|[[Qt Contributors Summit 2019 HighDpi|HighDpi]]
|-
|-
|16:00 - 17:00
|16:00 - 17:00
| colspan="4" style="text-align: center; background-color:#fbfde5;" | '''Plenary Session'''
| colspan="4" style="text-align: center; background-color:#fbfde5;" | '''Plenary Session'''
(afterwards: Free Beers at the Reception Room)
|}
|}


Line 125: Line 126:
|-
|-
|9:00 - 9:40
|9:00 - 9:40
| rowspan="2" |QtCore
| rowspan="2" |[[Qt Contributors Summit 2019 Program|QtCore]]
| rowspan="2" |[[Qt Contributors Summit 2019 Program#Qt CMake Workshop|Qt CMake Workshop]]
| rowspan="2" |[[Qt Contributors Summit 2019 Program#Qt CMake Workshop|Qt CMake Workshop]]
|  
|  
|[[Qt Contributors Summit 2019 Program#Fate of Qt Solutions|Fate of Qt Solutions?]]
|[[Qt Contributors Summit 2019 Qt Solutions|Fate of Qt Solutions?]]
|-
|-
|9:50 - 10:30
|9:50 - 10:30
|  
|  
| [[Qt Contributors Summit 2019 Program#Qt Machine Learning and Math|Qt Machine Learning and Math]]
|
|-
|-
|10:30 - 10:50
|10:30 - 10:50
Line 141: Line 142:
| rowspan="2" |[[Qt Contributors Summit 2019 Program#Qt CMake Workshop|Qt CMake Workshop]]
| rowspan="2" |[[Qt Contributors Summit 2019 Program#Qt CMake Workshop|Qt CMake Workshop]]
| [[Qt Contributors Summit 2019 Program#Evolving the Qt Project Security Policy|Evolving the Qt Project Security Policy]]
| [[Qt Contributors Summit 2019 Program#Evolving the Qt Project Security Policy|Evolving the Qt Project Security Policy]]
| [[Qt Contributors Summit 2019 PRogram#Qt for Python and beyond|Qt for Python and beyond]]
| [[Qt_Contributors_Summit_2019_Program/Qt_for_Python_and_beyond|Qt for Python and beyond]]
|-
|-
|11:40 - 12:20
|11:40 - 12:20
| [[Qt Contributors Summit 2019 Program#Qt WebEngine Release Management|Qt WebEngine Release Management]]
| [[Qt Contributors Summit 2019 Program#Qt WebEngine Release Management|Qt WebEngine Release Management]]
| [[Qt Contributors Summit 2019 Program#Qt for Python Documentation|Qt for Python Documentation]]
| [[Qt_Contributors_Summit_2019_Program/Qt_for_Python_Documentation|Qt for Python Documentation]]
|-
|-
|12:20 - 13:20
|12:20 - 13:20
Line 156: Line 157:
|
|
|-
|-
|14:00 - 15:00
|14:10 - 14:50
|Qt Core spill over?
|[[Qt Contributors Summit 2019 Program#Qt CMake Workshop|Qt CMake Workshop]]
|[[Qt Contributors Summit 2019 Program#Qt Wayland Client and extensions|Qt Wayland Client and extensions]]
| [[Qt_Contributors_Summit_2019_Program/Qt_Machine_Learning_and_Math|Qt Machine Learning and Math]]
|-
|15:00 - 16:00
| colspan="4" style="text-align: center; background-color:#fbfde5;" | '''Plenary Session'''
| colspan="4" style="text-align: center; background-color:#fbfde5;" | '''Plenary Session'''
|}
|}


== Sessions ==
== Sessions ==
=== QtCore ===
Thiago Macieira
[[Qt Contributor Summit 2019 - QtCore]]


=== Agenda Overview ===
=== Agenda Overview ===
Line 166: Line 178:


=== QML Version 3 ===
=== QML Version 3 ===
''Ulf Hermann''
=== QtQml ===
[[Qt Contributor Summit 2019 - QtQml]]
''Ulf Hermann''
''Ulf Hermann''


Line 172: Line 189:


State of Qt6 port to CMake.
State of Qt6 port to CMake.
[[CMake Port/Workshop 2019 11|Session notes]].


=== Branch Policy for Qt 6 ===
=== Branch Policy for Qt 6 ===
Line 179: Line 197:


A simpler workflow where all changes go into the dev branch, and are then cherry-picked into those stable branches where we want them, perhaps supported by some automation, seems to be more common in software projects. It provides different trade-offs, which we should discuss.
A simpler workflow where all changes go into the dev branch, and are then cherry-picked into those stable branches where we want them, perhaps supported by some automation, seems to be more common in software projects. It provides different trade-offs, which we should discuss.
[[Qt_Contributors_Summit_2019_-_Branch_Policy|Session Notes]]


=== KDE experience in attracting and nurturing contributors ===
=== KDE experience in attracting and nurturing contributors ===
Line 190: Line 210:
Qt Marketplace status, existing and planned features, launch schedule, content publishing process, and content usage.
Qt Marketplace status, existing and planned features, launch schedule, content publishing process, and content usage.


Jira item: https://bugreports.qt.io/browse/QTPM-278
You may create bugs and suggestions in QtBug, but please link to the task above.
==== Publisher flow ====
* Publisher page
** Rest APIs for contributing to Qt Marketplace would be more than welcome
* Repo/package publishing with the IFW
** Very time consuming to create repos for each Qt platform and for each Qt patch version - especially if there is very few users for the patch version
*** Could the IFW package management changed so that packages would not be required for patch version, if nothing has changed
*** To create IFW packages for the marketplace may take several weeks
** The number of binary installation is not expected to be large even in the future
*** Currently five extensions from four publishers 
* Package manager
** Would be needed for source building
** Conan/vcpkg seem still the best options
*** Conan works with many build systems, including Yocto. Vcpkg woks only with CMake.
*** Conan index would help in managing repos. Needs to be checked, if the commercial license really needed
*** Conan UX considered significantly better
* Update frequency
** For extensions in public/customer reports, the updates may be as frequent as needed
*** Should be limited though to avoid some cyberattacks
** Qt Creator plugins distributed via the IFW would need to be validated in Qt Creator beta + final releases
*** Gives six weeks for the contributor to update plugins for the new Qt Creator version
====User flow====
* Building extensions
** Qt Creator plugins
*** Packaging wizard exists, but not available in public yet
*** Qt Creator API freezing is not a feasible option
**** Plugin APIs need changes to make the maintenance work easier
**** What would be a minimal API set, which could be frozen and would bring value to plugin developers at the same time
**** Rather than freezing some of the Creator APIs, it could be more useful to provide Python APIs?
*** Having a Qt Creator environment available in the installer to help building plugins with the right compiler, headers etc. would be beneficial - this should already be the case
** Building in the IDE or cloud
*** IDE most feasible option in the short term
*** Some contributors expect us to support IDE builds
* Binaries
** Could we use bundles, containing plugins for several Qt Creator versions
=== Qt 6 Graphics Overview ===
=== Qt 6 Graphics Overview ===
''Laszlo & co.''
''Laszlo & co.''


Let's have an overview of graphics related changes in Qt 6. The keynote will probably mention some of these, the goal in this session is to expand on them a bit. There can then be deeper individual discussions on specific topics during the next two days, if there is interest.
Let's have an overview of graphics related changes in Qt 6. The keynote will probably mention some of these, the goal in this session is to expand on them a bit. There can then be deeper individual discussions on specific topics during the next two days, if there is interest.
[https://github.com/alpqr/talks/blob/master/Qt_Contributors_Summit_2019/qt6gfx_qtcs2019.pdf Slides from the presentation]


=== C++17 language and std library features for Qt 6  ===
=== C++17 language and std library features for Qt 6  ===
''Ville Voutilainen''
''Ville Voutilainen''


With Qt 6 we want to be able to use some C++ 17 language and std library features. Not all compilers and platforms we are going to care about by the time Qt 6 comes around will support evertyhing, so this needs a balanced discussion of up- and down-sides, leading to a pragmatic subset that we can rely on. See https://bugreports.qt.io/browse/QTBUG-77477 for details.
With Qt 6 we want to be able to use some C++ 17 language and std library features. Not all compilers and platforms we are going to care about by the time Qt 6 comes around will support evertyhing, so this needs a balanced discussion of up- and down-sides, leading to a pragmatic subset that we can rely on. See https://bugreports.qt.io/browse/QTBUG-77477 for details. See [[Cpp17FeaturesWeReallyWant]] for other ruminations.
 
[[Qt Contributor Summit 2019 - C++17 Features Notes]]


=== Code Review: Sharing the load ===
=== Code Review: Sharing the load ===
Line 206: Line 268:
Sometimes we struggle to keep up with all the reviews we're asked to look at.
Sometimes we struggle to keep up with all the reviews we're asked to look at.
How can we organise this so that no-one waits too long but all of us still have time to hack on code ?
How can we organise this so that no-one waits too long but all of us still have time to hack on code ?
Time To Be Arranged.
 
[[Code Review: Sharing the load]]


=== API Review Process ===
=== API Review Process ===
Line 212: Line 275:


As experienced during Qt 5.13 and Qt 5.14 releases, some changes to APIs were getting feedback only very late in the release process, when the header diff was uploaded for sanity review. This seems a bit late. I'd like to see if we can find a more effective way of integrating API reviews into the general code review process. Perhaps changes that change public headers require a slightly different process than fixes and changes that touch only the implementation.
As experienced during Qt 5.13 and Qt 5.14 releases, some changes to APIs were getting feedback only very late in the release process, when the header diff was uploaded for sanity review. This seems a bit late. I'd like to see if we can find a more effective way of integrating API reviews into the general code review process. Perhaps changes that change public headers require a slightly different process than fixes and changes that touch only the implementation.
[[Qt_Contributors_Summit_2019_-_API_Review_Process|Session Notes]]


=== Evolving the Qt Project Security Policy ===
=== Evolving the Qt Project Security Policy ===
Line 240: Line 305:
We aim to focus on having a welcoming and easy-to-do process for getting more people involved in contributing to Qt.
We aim to focus on having a welcoming and easy-to-do process for getting more people involved in contributing to Qt.
[https://bugreports.qt.io/browse/QTBUG-74429 Check the related task on JIRA]
[https://bugreports.qt.io/browse/QTBUG-74429 Check the related task on JIRA]
[[Qt_Contributors_Summit_2019_-_Contributor_Experience|Session Notes]]


=== Platform-specific APIs in Qt 6 ===
=== Platform-specific APIs in Qt 6 ===
'''Tor Arne Vestbø''', '''Johan Helsing''', '''Paul Olav Tvete'''
'''Tor Arne Vestbø''', '''Johan Helsing''', '''Paul Olav Tvete'''


There are currently multiple different ways of exposing platform-specific APIs in Qt (Qt Platform Headers, Qt Platform Native Interface, Qt Platform Support, and Qt Foo Extras among others). Qt 6 is a good time to take a look at how this can be improved and coordinated better.  
There are currently multiple different ways of exposing platform-specific APIs in Qt (Qt Platform Headers, Qt Platform Native Interface, Qt Platform Support, and Qt Foo Extras among others). Qt 6 is a good time to take a look at how this can be improved and coordinated better.
 
 
[[Qt Contributor Summit 2019 - Platform-specific APIs in Qt 6]]


=== Refurbishing Qt Widgets internals ===  
=== Refurbishing Qt Widgets internals ===  
Line 250: Line 320:


This is a session to discuss changes to the underlying architecture in Qt Widgets, such as the backing store and parent/child hierarchy.
This is a session to discuss changes to the underlying architecture in Qt Widgets, such as the backing store and parent/child hierarchy.
[[Qt Contributor Summit 2019 - Refurbishing Qt Widgets internals]]


=== Future of QStyle for widgets and controls ===
=== Future of QStyle for widgets and controls ===
'''Shawn Rutledge, Richard Gustavsen, Uwe Rathman'''
'''Shawn Rutledge, Richard Gustavsen, Uwe Rathman'''


This is a session to discuss a potential architecture for styles that can be used to render both widgets and Qt Quick Controls, making the scene graph available for use in styles, perhaps using techniques similar to QSkinny, perhaps enabling Qt widgets and controls to be backed by native platform widgets (at least on some platforms where it's most necessary), etc.  
This is a session to discuss a potential architecture for styles that can be used to render both widgets and Qt Quick Controls, making the scene graph available for use in styles, perhaps using techniques similar to QSkinny, perhaps enabling Qt widgets and controls to be backed by native platform widgets (at least on some platforms where it's most necessary), etc.
 
[[Qt_Contributors_Summit_2019_-_QStyle|Session Notes]]


=== Qt Wayland Client and extensions ===
=== Qt Wayland Client and extensions ===
Line 261: Line 335:
What existing extensions should we support, and should we propose any new extensions for wayland-protocols? What functionality is missing from Qt Wayland Client, and how can we improve cooperation with KDE and other stakeholders? (note that there is a separate session about the general approach to platform-specific APIs in future Qt versions.)
What existing extensions should we support, and should we propose any new extensions for wayland-protocols? What functionality is missing from Qt Wayland Client, and how can we improve cooperation with KDE and other stakeholders? (note that there is a separate session about the general approach to platform-specific APIs in future Qt versions.)


=== High DPI ===
[[Qt Contributors Summit 2019 - Qt Wayland Client and extensions]]
'''Friedemann Kleint'''
 
Recap of High DPI, future plans
 
=== Fate of Qt Solutions ===
'''Friedemann Kleint'''
 
There are some gems in the current solutions (Singleton, property editor, etc), should they live on in Qt 6 and how?


=== Clang-based cpp parser for lupdate ===
=== Clang-based cpp parser for lupdate ===
Line 281: Line 347:
* Why a new cpp parser (what is gained, what is lost)?
* Why a new cpp parser (what is gained, what is lost)?
* How can cmake facilitate the use of the new clang-based parser?
* How can cmake facilitate the use of the new clang-based parser?
* [[Qt Contributors Summit 2019 - lupdate|Session Notes]]


=== moc and QMetaObject ===
=== moc and QMetaObject ===
Line 290: Line 357:
* Should we make a clang port of moc. clang tools are already used by qt creator/qdoc, maybe lupdate, so this wouldn't be a new dependency, but it would become a mandatory dependency. This would allow moc to be much better at handling "advanced" C++ features. But clang would probably be much slower at parsing than moc currently is.
* Should we make a clang port of moc. clang tools are already used by qt creator/qdoc, maybe lupdate, so this wouldn't be a new dependency, but it would become a mandatory dependency. This would allow moc to be much better at handling "advanced" C++ features. But clang would probably be much slower at parsing than moc currently is.
* While moc has to stay to keep source compatibility with Qt5, should we allow users not to need to rely on moc using something similar to https://github.com/woboq/verdigris , or even encourage it? Recent change with QML3 which will force the use of a moc-json generated file goes against it.
* While moc has to stay to keep source compatibility with Qt5, should we allow users not to need to rely on moc using something similar to https://github.com/woboq/verdigris , or even encourage it? Recent change with QML3 which will force the use of a moc-json generated file goes against it.
 
* [[Qt Contributors Summit 2019 - moc and QMetaObject|Session Notes]]
=== Qt 6 Migration strategy ===
'''Friedemann Kleint'''
 
* How can we migration to Qt 6 as easy as possible and start already in Qt 5?
* For example, a unified string theory would be a relevant topic


=== Fuzzing Qt ===  
=== Fuzzing Qt ===  
Line 304: Line 366:
* Which code needs fuzz testing the most?<br />I think of functions that handle input from possibly untrusted sources. Please propose such or let me know about other criteria.
* Which code needs fuzz testing the most?<br />I think of functions that handle input from possibly untrusted sources. Please propose such or let me know about other criteria.
* What's missing to test Qt in [https://github.com/google/oss-fuzz oss-fuzz]?
* What's missing to test Qt in [https://github.com/google/oss-fuzz oss-fuzz]?
[[Qt_Contributors_Summit_2019_-Fuzzing_Qt|Session Notes]]


=== Qt CMake Workshop ===  
=== Qt CMake Workshop ===  
Line 316: Line 380:
Python has shown us how a simple API can transform a whole language, just by providing the proper tools.
Python has shown us how a simple API can transform a whole language, just by providing the proper tools.
The C++ performance could be a game-changer regarding Data Science, and it has been used in frameworks like [https://github.com/pytorch/pytorch PyTorch].
The C++ performance could be a game-changer regarding Data Science, and it has been used in frameworks like [https://github.com/pytorch/pytorch PyTorch].
[[Qt Contributors Summit 2019 Program/Qt Machine Learning and Math|Session notes]]


=== Qt WebEngine Release Management ===
=== Qt WebEngine Release Management ===
Line 330: Line 396:
Currently, there are many issues with the documentation of the project: [https://bugreports.qt.io/browse/PYSIDE-691 C++ snippets], [https://bugreports.qt.io/browse/PYSIDE-1106 Toolchain], [https://bugreports.qt.io/browse/PYSIDE-1067 Not optimal structure, unclear flow], [https://bugreports.qt.io/browse/PYSIDE-841 mix of tutorials, missing examples], etc.
Currently, there are many issues with the documentation of the project: [https://bugreports.qt.io/browse/PYSIDE-691 C++ snippets], [https://bugreports.qt.io/browse/PYSIDE-1106 Toolchain], [https://bugreports.qt.io/browse/PYSIDE-1067 Not optimal structure, unclear flow], [https://bugreports.qt.io/browse/PYSIDE-841 mix of tutorials, missing examples], etc.
The idea of this session is to define both the design, and content of the Qt for Python documentation for future releases.
The idea of this session is to define both the design, and content of the Qt for Python documentation for future releases.
[[Qt Contributors Summit 2019 Program/Qt for Python Documentation|Session notes]]


=== Rethinking serialization for Qt6 ===
=== Rethinking serialization for Qt6 ===
Line 344: Line 412:


In this talk I would like to review how Qt as whole helps in making embedded devices. There is a variety of offerings, solutions and even real Qt modules dedicated to or just relevant for embedded devices for one or another use case. I think, the total is currently almost unbeatable and at the same time, it is very hard to find. What is that total and how can we make it more accessible? Should we? Is this something contributors should care? Is there an actual interest in the field? I wish to find out. Do you?
In this talk I would like to review how Qt as whole helps in making embedded devices. There is a variety of offerings, solutions and even real Qt modules dedicated to or just relevant for embedded devices for one or another use case. I think, the total is currently almost unbeatable and at the same time, it is very hard to find. What is that total and how can we make it more accessible? Should we? Is this something contributors should care? Is there an actual interest in the field? I wish to find out. Do you?
The slides are available [https://sfa.luxoft.com/f/55e9eac4a296424badaa/ here]. The link expires after Jan 20, 2020.
Notes:
* There is general agreement that there is a need in Qt for a hand-on guidance on an application architecture applicable on embedded platforms
* Current examples and guides in the doc do not tell people how to create “serious” app right way. Most of them are focusing on a given Qt feature and some may even be a kind of misleading, e.g. https://doc-snapshots.qt.io/qt5-5.14/qtdoc-tutorials-alarms-example.html named as “Getting Started Programming with Qt Quick” tells people to write an app completely in JavaScript and even provides a simple model for a calendar written only in QML
* It was seen as doubtful if there should really be an new “application platform”, since this has a danger to become too specific and limit the flexibility Qt provides
* A form of “best practice” would be a better way to go instead of an own complete application architecture. The latter seems to be too sophisticated at the begining
* Addressing and reflecting this in the docs is mandatory, still there should be a reference implementation along with some dedicated examples
* Quite some embedded projects still do ONE app. Further splitting it in more sub-apps might be seen as an overkill. This also means that any new works on an application  architecture should keep considering this as a valid case along multi-application and multi-process cases
* It still was not clear if such a work is of interest for a broad community or if it is for The Qt Company as the commercial entity behind Qt. This is due to the fact that Qt for Device Creation and other related projects, like Qt Automotive Suite are seen as commercial programs with a limited involvement from the community
Next steps:
* have a review discussion with stakeholders in The Qt Company
* Define the scope for the doc changes and an outline for the “best practice” guide and app


=== Releasing ===
=== Releasing ===
'''Jani Heikkinen'''
'''Jani Heikkinen'''
[[Qt Contributor Summit 2019 - Releasing Notes]]


=== Remote display of Qt applications in Qt 6 ===
=== Remote display of Qt applications in Qt 6 ===
Line 357: Line 443:


Let's have an overview of network related changes in Qt 6. The idea is to iterate through the existing list and verify nothing is missing and/or should be adapted.
Let's have an overview of network related changes in Qt 6. The idea is to iterate through the existing list and verify nothing is missing and/or should be adapted.
[[Qt_Contributors_Summit_2019_-_Qt 6 Network Overview|Session Notes]]
=== HighDpi ===
'''Friedemann Kleint'''
[[Qt Contributors Summit 2019 HighDpi|Session Notes]]
=== Source incompatible changes/Migration ===
'''Friedemann Kleint'''
[[Qt Contributors Summit 2019 Qt 6 Changes / Migration|Session Notes]]
=== Fate of Qt Solutions? ===
'''Friedemann Kleint'''
[[Qt Contributors Summit 2019 Qt Solutions|Session Notes]]
=== QtGui RHI 3D ===
'''Laszlo Agocs'''
[[Qt Contributor Summit 2019 - QtGui RHI 3D|Session Notes]]

Latest revision as of 11:29, 3 December 2019

Back to Qt Contributors Summit 2019

Please add a longer session description with topic owner in the lower part of the page!

Tuesday, 2019-11-19

First day is reserved for topics that are of interest to the majority, and main location is the Assembly Hall. If you have something to present please coordinate beforehand on IRC or via mail.

Time Assembly Hall
8:00 - 9:00 Registration
9:00 - 9:20 Introduction and sponsors
9:20 - 10:30 Keynote: Towards Qt 6 (Lars Knoll)
10:30 - 11:00 Coffee Break
11:00 - 11:30 QML Version 3
11:30 - 12:00 CMake Port
12:00 - 13:30 Lunch Break
13:30 - 14:00 Branch Policy for Qt 6
14:00 - 14:30 Qt Marketplace
14:30 - 15:00 KDE experience in attracting and nurturing contributors
15:00 - 15:30 Coffee Break
15:30 - 16:00 Qt 6 Graphics Overview
16:00 - 16:30 Qt for Python in Qt 6
16:30 - 17:30 Agenda Overview

Wednesday, 2019-11-20

Time Assembly Hall 1.3.14 (Zoo, 16 people) 1.1.9 (Landsberger Allee, 21 people) 1.1.8 (Greifwalder Str, 17 people)
9:00 - 9:40 Qt Marketplace QtQml Remote display of Qt applications in Qt 6
9:50 - 10:30 API Review Process Qt 6 Network Overview
10:30 - 10:50 Coffee Break
10:50 - 11:30 Refurbishing Qt Widgets internals Clang-based cpp parser for lupdate Code Review: Sharing the load Available, hidden and missing gems on the way of using Qt on embedded devices
11:40 - 12:20 Improve the contributor experience of the Qt project Qt 6 Changes / Migration
12:20 - 13:20 Lunch Break
13:20 - 14:00 C++17 language and std library features for Qt 6 Qt application lifecycle (startup, shutdown, sessions) Releasing
14:10 - 14:50 QtGui, RHI & 3D
14:50 - 15:10 Coffee Break
15:10 - 15:50 BoF: Fuzzing Qt Branching policy Rethinking serialization for Qt6 HighDpi
16:00 - 17:00 Plenary Session

(afterwards: Free Beers at the Reception Room)

Thursday, 2019-11-21

Time Assembly Hall 1.3.14 (Zoo, 16 people) 1.1.9 (Landsberger Allee, 21 people) 1.1.8 (Greifwalder Str, 17 people)
9:00 - 9:40 QtCore Qt CMake Workshop Fate of Qt Solutions?
9:50 - 10:30
10:30 - 10:50 Coffee Break
10:50 - 11:30 Platform-specific APIs in Qt 6 Qt CMake Workshop Evolving the Qt Project Security Policy Qt for Python and beyond
11:40 - 12:20 Qt WebEngine Release Management Qt for Python Documentation
12:20 - 13:20 Lunch Break
13:20 - 14:00 moc and QMetaObject Qt CMake Workshop Future of QStyle for widgets and controls
14:10 - 14:50 Qt Core spill over? Qt CMake Workshop Qt Wayland Client and extensions Qt Machine Learning and Math
15:00 - 16:00 Plenary Session

Sessions

QtCore

Thiago Macieira

Qt Contributor Summit 2019 - QtCore

Agenda Overview

The Qt Contributors Summit is mostly organized as an un-conference. In addition to the sessions already proposed here, we assume that participants will come up with topics that they'd like to discuss or work on. At the end of Day 1, anyone that has a session proposal will have a chance to pitch their session, and all participants can indicate which sessions they'd like to participate in. We'll then create the agenda for days 2 and 3, trying to match the sessions with the biggest interests to the largest rooms. The agenda will be updated here.

QML Version 3

Ulf Hermann

QtQml

Qt Contributor Summit 2019 - QtQml

Ulf Hermann

CMake Port

Alexandru Croitor

State of Qt6 port to CMake. Session notes.

Branch Policy for Qt 6

Volker Hilsheimer

The current flow of changes in which fixes go into a stable branch, and are then up-merged gradually through several branches before they reach dev, can cause significant delays, results in a lot of changes in those stable branches, requires a lot of process work that provides very little enjoyment to the people responsible for it, and clutters the dev branch with merge commits. The approach has some benefits as long as it applies cleanly, i.e. it avoids duplicate commits, but with the dev branch having become Qt 6 with large scale refactoring and incompatible changes, it doesn't apply cleanly anymore anyway.

A simpler workflow where all changes go into the dev branch, and are then cherry-picked into those stable branches where we want them, perhaps supported by some automation, seems to be more common in software projects. It provides different trade-offs, which we should discuss.

Session Notes

KDE experience in attracting and nurturing contributors

David Edmundson

KDE has been a primarily volunteer driven project for its 20+ year lifespan. Attracting and keeping volunteers can be a difficult process, but there are many easy steps that can have a positive return. By sharing what we do successfully in KDE, we hope to kickstart a discussion of what steps we can emulate in Qt to improve the number of contributor contributions.

Qt Marketplace

Tino Pyssysalo and Marko Finnig

Qt Marketplace status, existing and planned features, launch schedule, content publishing process, and content usage.

Jira item: https://bugreports.qt.io/browse/QTPM-278

You may create bugs and suggestions in QtBug, but please link to the task above.

Publisher flow

  • Publisher page
    • Rest APIs for contributing to Qt Marketplace would be more than welcome
  • Repo/package publishing with the IFW
    • Very time consuming to create repos for each Qt platform and for each Qt patch version - especially if there is very few users for the patch version
      • Could the IFW package management changed so that packages would not be required for patch version, if nothing has changed
      • To create IFW packages for the marketplace may take several weeks
    • The number of binary installation is not expected to be large even in the future
      • Currently five extensions from four publishers
  • Package manager
    • Would be needed for source building
    • Conan/vcpkg seem still the best options
      • Conan works with many build systems, including Yocto. Vcpkg woks only with CMake.
      • Conan index would help in managing repos. Needs to be checked, if the commercial license really needed
      • Conan UX considered significantly better
  • Update frequency
    • For extensions in public/customer reports, the updates may be as frequent as needed
      • Should be limited though to avoid some cyberattacks
    • Qt Creator plugins distributed via the IFW would need to be validated in Qt Creator beta + final releases
      • Gives six weeks for the contributor to update plugins for the new Qt Creator version

User flow

  • Building extensions
    • Qt Creator plugins
      • Packaging wizard exists, but not available in public yet
      • Qt Creator API freezing is not a feasible option
        • Plugin APIs need changes to make the maintenance work easier
        • What would be a minimal API set, which could be frozen and would bring value to plugin developers at the same time
        • Rather than freezing some of the Creator APIs, it could be more useful to provide Python APIs?
      • Having a Qt Creator environment available in the installer to help building plugins with the right compiler, headers etc. would be beneficial - this should already be the case
    • Building in the IDE or cloud
      • IDE most feasible option in the short term
      • Some contributors expect us to support IDE builds
  • Binaries
    • Could we use bundles, containing plugins for several Qt Creator versions

Qt 6 Graphics Overview

Laszlo & co.

Let's have an overview of graphics related changes in Qt 6. The keynote will probably mention some of these, the goal in this session is to expand on them a bit. There can then be deeper individual discussions on specific topics during the next two days, if there is interest.

Slides from the presentation

C++17 language and std library features for Qt 6

Ville Voutilainen

With Qt 6 we want to be able to use some C++ 17 language and std library features. Not all compilers and platforms we are going to care about by the time Qt 6 comes around will support evertyhing, so this needs a balanced discussion of up- and down-sides, leading to a pragmatic subset that we can rely on. See https://bugreports.qt.io/browse/QTBUG-77477 for details. See Cpp17FeaturesWeReallyWant for other ruminations.

Qt Contributor Summit 2019 - C++17 Features Notes

Code Review: Sharing the load

Eddy

Sometimes we wait and wait for anyone to review our changes. Sometimes we struggle to keep up with all the reviews we're asked to look at. How can we organise this so that no-one waits too long but all of us still have time to hack on code ?

Code Review: Sharing the load

API Review Process

Volker Hilsheimer

As experienced during Qt 5.13 and Qt 5.14 releases, some changes to APIs were getting feedback only very late in the release process, when the header diff was uploaded for sanity review. This seems a bit late. I'd like to see if we can find a more effective way of integrating API reviews into the general code review process. Perhaps changes that change public headers require a slightly different process than fixes and changes that touch only the implementation.

Session Notes

Evolving the Qt Project Security Policy

Volker Hilsheimer

During summer, the Qt Project Security Policy was moved from a wiki page into QUIP-15, and during that review process, some changes and additions were proposed to strengthen the project's capability to respond to security issues. Those changes were not taken into the QUIP as part of the move, since for the moment we only wanted to move the content. Suggestions included a clearer statement how security fixes are applied to LTS releases; the integration of CVE handling when disclosing vulnerabilities; the documentation of processes established by the Qt Company; and a general review of the way the "core team of developers" is organized, and operating.

Discussing these (and additional) proposals, and agreeing on what should become part of the policy (and thus the responsibility of the Qt project) is the purpose of this session. A proposal is available here: https://codereview.qt-project.org/c/meta/quips/+/278819

Qt for Python and beyond

Cristián Maureira-Fredes

After one year since the official release of Qt for Python we have been getting many new ideas for features to include in the next releases. Most of the features are explained in the latest blog post we wrote, but nevertheless we should try to build the next versions in favor of the Qt ecosystem, this means not only improving the Qt for Python project, but more like answering the question "How Qt for Python can improve the Qt project?". Please join us in this session to discuss how we can make Qt for Python a first-class citizen in the project by giving it more responsibility.

Improve the contributor experience of the Qt project

Cristián Maureira-Fredes

After the following steps:

  • Creating Qt account,
  • Creating Gerrit account,
  • Agreeing with the CLA,
  • Configure gerrit locally.

You are ready to start contributing.

If you think that it is too much, you should join this discussion. We aim to focus on having a welcoming and easy-to-do process for getting more people involved in contributing to Qt. Check the related task on JIRA

Session Notes

Platform-specific APIs in Qt 6

Tor Arne Vestbø, Johan Helsing, Paul Olav Tvete

There are currently multiple different ways of exposing platform-specific APIs in Qt (Qt Platform Headers, Qt Platform Native Interface, Qt Platform Support, and Qt Foo Extras among others). Qt 6 is a good time to take a look at how this can be improved and coordinated better.


Qt Contributor Summit 2019 - Platform-specific APIs in Qt 6

Refurbishing Qt Widgets internals

Tor Arne Vestbø, Johan Helsing, Paul Olav Tvete

This is a session to discuss changes to the underlying architecture in Qt Widgets, such as the backing store and parent/child hierarchy.

Qt Contributor Summit 2019 - Refurbishing Qt Widgets internals

Future of QStyle for widgets and controls

Shawn Rutledge, Richard Gustavsen, Uwe Rathman

This is a session to discuss a potential architecture for styles that can be used to render both widgets and Qt Quick Controls, making the scene graph available for use in styles, perhaps using techniques similar to QSkinny, perhaps enabling Qt widgets and controls to be backed by native platform widgets (at least on some platforms where it's most necessary), etc.

Session Notes

Qt Wayland Client and extensions

Johan Helsing, Paul Olav Tvete

What existing extensions should we support, and should we propose any new extensions for wayland-protocols? What functionality is missing from Qt Wayland Client, and how can we improve cooperation with KDE and other stakeholders? (note that there is a separate session about the general approach to platform-specific APIs in future Qt versions.)

Qt Contributors Summit 2019 - Qt Wayland Client and extensions

Clang-based cpp parser for lupdate

Lucie Gerard

Introduction to the new cpp parser for lupdate, based on clang-tooling.

Topics:

  • How to build a clang-tool?
  • What are the requirement to use the new cpp parser?
  • Why a new cpp parser (what is gained, what is lost)?
  • How can cmake facilitate the use of the new clang-based parser?
  • Session Notes

moc and QMetaObject

Olivier Goffart

  • What future do the Qt project wants for moc?
  • Many changes are talked about for QMetaObject in Qt6: automatic QMetaType registration, hash-table based lookups, merging with the property cache, ...
  • moc currently hasn't still fully be ported to support C++11 yet. Features such as raw literals, trailing returns and other will confuse moc. Should moc be updated for these features, or:
  • Should we make a clang port of moc. clang tools are already used by qt creator/qdoc, maybe lupdate, so this wouldn't be a new dependency, but it would become a mandatory dependency. This would allow moc to be much better at handling "advanced" C++ features. But clang would probably be much slower at parsing than moc currently is.
  • While moc has to stay to keep source compatibility with Qt5, should we allow users not to need to rely on moc using something similar to https://github.com/woboq/verdigris , or even encourage it? Recent change with QML3 which will force the use of a moc-json generated file goes against it.
  • Session Notes

Fuzzing Qt

Robert Löhning

Fuzzing could already find a couple of crashes in Qt, including security related. Let's have a birds of a feather session on how to make the most of it.

  • How to try it locally?
  • Which code needs fuzz testing the most?
    I think of functions that handle input from possibly untrusted sources. Please propose such or let me know about other criteria.
  • What's missing to test Qt in oss-fuzz?

Session Notes

Qt CMake Workshop

Alexandru Croitor

Help out with building Qt6 with CMake. Provide feedback on things that are important to you.

Qt Machine Learning and Math

Cristián Maureira-Fredes

What C++ and more precisely, Qt, can provide to the Machine Learning community? What about simple Math? Python has shown us how a simple API can transform a whole language, just by providing the proper tools. The C++ performance could be a game-changer regarding Data Science, and it has been used in frameworks like PyTorch.

Session notes

Qt WebEngine Release Management

Allan Sandfeld Jensen

How should WebEngine be release around Qt 6.0 and in Qt 6 times. Should WebEngine have a Chromium update for 5.15, a sort of 5.16. Should WebEngine support building with both Qt 5 and Qt 6 for a time?

Should Qt WebEngine decouple and how? It could soft follow the Qt releases but not maintain older versions and instead support building with older Qt. This requires changes to build system and packaging. Can we get rid of all private Qt api usage.

Qt for Python Documentation

Cristián Maureira-Fredes

Currently, there are many issues with the documentation of the project: C++ snippets, Toolchain, Not optimal structure, unclear flow, mix of tutorials, missing examples, etc. The idea of this session is to define both the design, and content of the Qt for Python documentation for future releases.

Session notes

Rethinking serialization for Qt6

Arnaud Clère

Serialization is an old problem, still, we keep writing code to serialize C++ data in specific ways again and again. With Qt5 for instance, you may have to code: QDebug << to debug it, QDataStream << and >> to marshal it to another Qt application, use QSettings to make it persistent, QJson* or QXml* to convey it on the web, QCbor* for the IoT, and QAbstractModelItem for the DB/GUI. Even though such code needs to be customized here and there, it is mostly boilerplate code. So, can we make this simpler for Qt6?

Indeed, I will present a solution that enables to read/write C++ data from/to any of those APIs by defining a single function which can be easily customized to specific needs. Its runtime overhead being almost negligible, I will go on talking about many data formats from QDataStream to XML since that is where the actual performance/safety/interoperability tradeoffs are made. That should trigger an interesting discussion on the tradeoffs made by the only broadly implemented serialization for Qt types: QDataStream.

Finally, I hope to trigger enough interest from the community to review and polish this proposal, and to enable more serialization choices for most Qt6 types.

Available, hidden and missing gems on the way of using Qt on embedded devices

Vladimir Minenko

In this talk I would like to review how Qt as whole helps in making embedded devices. There is a variety of offerings, solutions and even real Qt modules dedicated to or just relevant for embedded devices for one or another use case. I think, the total is currently almost unbeatable and at the same time, it is very hard to find. What is that total and how can we make it more accessible? Should we? Is this something contributors should care? Is there an actual interest in the field? I wish to find out. Do you?

The slides are available here. The link expires after Jan 20, 2020.

Notes:

  • There is general agreement that there is a need in Qt for a hand-on guidance on an application architecture applicable on embedded platforms
  • Current examples and guides in the doc do not tell people how to create “serious” app right way. Most of them are focusing on a given Qt feature and some may even be a kind of misleading, e.g. https://doc-snapshots.qt.io/qt5-5.14/qtdoc-tutorials-alarms-example.html named as “Getting Started Programming with Qt Quick” tells people to write an app completely in JavaScript and even provides a simple model for a calendar written only in QML
  • It was seen as doubtful if there should really be an new “application platform”, since this has a danger to become too specific and limit the flexibility Qt provides
  • A form of “best practice” would be a better way to go instead of an own complete application architecture. The latter seems to be too sophisticated at the begining
  • Addressing and reflecting this in the docs is mandatory, still there should be a reference implementation along with some dedicated examples
  • Quite some embedded projects still do ONE app. Further splitting it in more sub-apps might be seen as an overkill. This also means that any new works on an application architecture should keep considering this as a valid case along multi-application and multi-process cases
  • It still was not clear if such a work is of interest for a broad community or if it is for The Qt Company as the commercial entity behind Qt. This is due to the fact that Qt for Device Creation and other related projects, like Qt Automotive Suite are seen as commercial programs with a limited involvement from the community

Next steps:

  • have a review discussion with stakeholders in The Qt Company
  • Define the scope for the doc changes and an outline for the “best practice” guide and app

Releasing

Jani Heikkinen

Qt Contributor Summit 2019 - Releasing Notes

Remote display of Qt applications in Qt 6

Jan Arne Petersen, Christoph Sterz

Discussion about API changes which makes it easier to provide remote display of Qt applications. Besides the transfer of the images/textures also input handling (multi-seat?) is relevant.

Qt 6 Network Overview

Timur Pocheptsov / Mårten Nordheim

Let's have an overview of network related changes in Qt 6. The idea is to iterate through the existing list and verify nothing is missing and/or should be adapted. Session Notes

HighDpi

Friedemann Kleint

Session Notes

Source incompatible changes/Migration

Friedemann Kleint

Session Notes

Fate of Qt Solutions?

Friedemann Kleint

Session Notes

QtGui RHI 3D

Laszlo Agocs

Session Notes

Retrieved from "https://wiki.qt.io/index.php?title=Qt_Contributors_Summit_2019_Program&oldid=36558"