[Development] QtCS19 Notes: Remote display of Qt applications in Qt 6
Hi, Following the notes taken on the remote display session: - Qt5 has webgl and vnc - Use-case duplicate displays ○ One local ○ One remote - TQtC Hackathon project ○ Stream the scene graph to another machine - Multi seat is problematic ○ Affect all current solutions ○ However, part of Wayland protocol - Option: Being able to have multiple QPA backends at the same time - use-cases ○ Remote mirror ○ Multiple displays ○ Virtual Keyboard and physical keyboard at the same time ○ … ○ Need to stay focused - Current understanding is that this is not 6.0 content ○ WebGL etc might not be ready within timeframe - "Multiplexing QPA" does help to shift any work beyond 6.0 and stay compatible with current API - Again, multiple inputs should be handled via wayland ○ Moved details to be discussed to wayland session - Proposal is to fix this based on specific project and not try to aim at an swiss army knife right from the beginning - While it is not part of current 6.0 plans, we should try to get the basics available ○ Enable multiple inputs (keyboards, cursors, …) - Where to draw a line? ○ Multiple cursors displayed?... - Anything else but wayland? ○ X11 tried this, but never got around to have something to be used ○ Are there any other options? No one knows… - Proposal Paul: ○ QPA API as a start ○ Then merges events to the application - Action Points: ○ How and who drives multi seat? ○ Need to get started with a pilot project based on Wayland ○ Multiplex solution seems most viable ○ Get user story in JIRA ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Notes from "C++17 language and std library features for Qt 6"
On Wednesday, 20 November 2019 20:20:29 CET Kari Oikarinen wrote: > ## Parallel STL algorithms > > We could allow parallel execution tags in our API to let users ask for > use of parallel algorithms. > > But what are the places in Qt API that actually need these? More data > analysis stuff (if developed) would find it helpful. But often users > get to choose their own algorithms and so can use parallel algorithms > without our containers needing to know about it. > > If a parallel STL implementation is not available, falling back to > single-threaded implementation is always an option. So support could > be utilized only when available and not demanded from all platforms. > Or the platfrom support can be a shim that still always processes > everything without parallelism. > > One problem with this is that it is a very recent addition in the standard libraries, and isn't even in any released version of libc++ yet. So using it would require MSVC 2019 and gcc 9, and a future version of clang. It could be useful for image handling though, and theoretically also for raster painting if for some reason the GPU isn't used. It could be opportunistically used when available though. It would be entirely internal, and just split some operations over multiple threads. But the things it would optimize are operations that would be even faster if done on the GPU instead. 'Allan ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Notes from "C++17 language and std library features for Qt 6"
I managed to mangle copy pasting to the mail, so probably better to read from the wiki page rather than read everything twice in a tricky order. On 20.11.2019 21.20, Kari Oikarinen wrote: > Hi! > > Here are the notes for the C++17 related session held today at QtCS. I > tried my best to capture the discussion, but there might still be a lot > of errors. > > Notes are also in the wiki at > https://wiki.qt.io/Qt_Contributor_Summit_2019_-_C%2B%2B17_Features_Notes > > # Language > > > ## if constexpr > > # Language > > > ## if constexpr > > Very useful for our containers. > > > ## Fold expressions > > Shortcut for handling parameter packs of vadiadic templates. No need > to write recursive template helpers. > > > ## Inline variable > > Volker: What is the impact of using inline variables to static data > initialization? How do we deal with `Q_GLOBAL_STATIC`? > > Inline variables are safer than static globals. Compiler and linker > guarantee that there will be just one definition. > > `Q_GLOBAL_STATIC` still provides lazy initialization. So inline > variables are not a full replacement. Any big globals that aren't > necessarily used should be gated by lazy initialization to avoid > constructing them unnecessarily. > > > ## Polymorphic lambdas > > What is it? It has auto as its parameter type. So the same lambda can > be used with multiple invocations with parameters of different types. > > Most common use is just for brevity. It gives you perfect forwarding > as well, if you use auto && as the type. > > But these are not API visible, just perhaps useful inside the > implementation. > > > ## Structured bindings > > QRect and QPoint might be possible candidates. But there will not be > many that this makes sense for. > > Some of these will already be aggregates and work automatically. But > perhaps they for example have user-defined constructors and so don't > fulfill the requirements of that. > > > ## Language attributes > > There are macros for many standard attributes, like nodiscard, > deprecated, fallthrough, likely and unlikely. > > When is the right point to remove this macros and use the attributes > directly? When all compilers support it. Although that causes pain > when backporting to older branches. > > That applies to all language features, though. Some backporting is > really hairy, like converting if constexpr solutions back to template > specializations. > > > ## Modules (C++20) > > Properly modularizing Qt is going to be a huge undertaking. There > should be some prototyping done by an energetic volunteer. > > There are rumors that moc generated code leads to some issues here. > > How will `QT_CONFIG()` macros work together with modules? Every > permutation would need to be shipped as a separate module. But they > are going to be constant within a built Qt. Not something the user of > the library can change. > > Modules are not supported by build systems (including qmake and CMake) > yet. CMake developer Kitware is working on it, though. > > > ## Coroutines (C++20) > > QDialog::call/exec() are already coroutines, but stackful ones. So > converting to them stackless is not really possible. But there might > be better candidates in networking or elsewhere with callbacks. > > Standard coroutines are quite cumbersome to use. Would we use an > external helper library with that or would Qt provide their own helper > for coroutines? Having Qt-friendly coroutine helpers would be nice. > > Test data supplying is currently a huge matrix of QVariants and is > actually a performance bottleneck for our tests. Using generators for > these might be helpful? They are not going to make a difference > compared to a good hand-written generator. So the performance issues > might be fixed with other approaches. > > > # Library > > Contributions to any of these would be welcome. > > > ## std::any > > std::any is like a QVariant that does not need registration. > > Could there be conversions between QVariant and std::any? Ville is > skeptical about how to do that. Olivier suggested adding support for > conversion from std::any to QVariant into QMetatype. But can that be > done with just a reference to `std::type_info`? > > std::any is a replacement for void\*. It knows the type that it holds. > > > ## std::filesystem > > Giuseppe: Should be use std::filesystem::path types consistently in > our APIs instead of QString? Ville: There should be a prototype patch > to see how big the effect is. I'm concerned that the impact would be > too big. > > Is std::filesystem::path API stable enough? Standard committee cares > about API stability a lot, so that's not a worry. Although some want a > new version of the API that uses std::expected. > > > ## Parallel STL algorithms > > We could allow parallel execution tags in our API to let users ask for > use of parallel algorithms. > > But what are the places in Qt API that actually need these? More data > analysis stuff (if
[Development] Notes from "C++17 language and std library features for Qt 6"
Hi! Here are the notes for the C++17 related session held today at QtCS. I tried my best to capture the discussion, but there might still be a lot of errors. Notes are also in the wiki at https://wiki.qt.io/Qt_Contributor_Summit_2019_-_C%2B%2B17_Features_Notes # Language ## if constexpr # Language ## if constexpr Very useful for our containers. ## Fold expressions Shortcut for handling parameter packs of vadiadic templates. No need to write recursive template helpers. ## Inline variable Volker: What is the impact of using inline variables to static data initialization? How do we deal with `Q_GLOBAL_STATIC`? Inline variables are safer than static globals. Compiler and linker guarantee that there will be just one definition. `Q_GLOBAL_STATIC` still provides lazy initialization. So inline variables are not a full replacement. Any big globals that aren't necessarily used should be gated by lazy initialization to avoid constructing them unnecessarily. ## Polymorphic lambdas What is it? It has auto as its parameter type. So the same lambda can be used with multiple invocations with parameters of different types. Most common use is just for brevity. It gives you perfect forwarding as well, if you use auto && as the type. But these are not API visible, just perhaps useful inside the implementation. ## Structured bindings QRect and QPoint might be possible candidates. But there will not be many that this makes sense for. Some of these will already be aggregates and work automatically. But perhaps they for example have user-defined constructors and so don't fulfill the requirements of that. ## Language attributes There are macros for many standard attributes, like nodiscard, deprecated, fallthrough, likely and unlikely. When is the right point to remove this macros and use the attributes directly? When all compilers support it. Although that causes pain when backporting to older branches. That applies to all language features, though. Some backporting is really hairy, like converting if constexpr solutions back to template specializations. ## Modules (C++20) Properly modularizing Qt is going to be a huge undertaking. There should be some prototyping done by an energetic volunteer. There are rumors that moc generated code leads to some issues here. How will `QT_CONFIG()` macros work together with modules? Every permutation would need to be shipped as a separate module. But they are going to be constant within a built Qt. Not something the user of the library can change. Modules are not supported by build systems (including qmake and CMake) yet. CMake developer Kitware is working on it, though. ## Coroutines (C++20) QDialog::call/exec() are already coroutines, but stackful ones. So converting to them stackless is not really possible. But there might be better candidates in networking or elsewhere with callbacks. Standard coroutines are quite cumbersome to use. Would we use an external helper library with that or would Qt provide their own helper for coroutines? Having Qt-friendly coroutine helpers would be nice. Test data supplying is currently a huge matrix of QVariants and is actually a performance bottleneck for our tests. Using generators for these might be helpful? They are not going to make a difference compared to a good hand-written generator. So the performance issues might be fixed with other approaches. # Library Contributions to any of these would be welcome. ## std::any std::any is like a QVariant that does not need registration. Could there be conversions between QVariant and std::any? Ville is skeptical about how to do that. Olivier suggested adding support for conversion from std::any to QVariant into QMetatype. But can that be done with just a reference to `std::type_info`? std::any is a replacement for void\*. It knows the type that it holds. ## std::filesystem Giuseppe: Should be use std::filesystem::path types consistently in our APIs instead of QString? Ville: There should be a prototype patch to see how big the effect is. I'm concerned that the impact would be too big. Is std::filesystem::path API stable enough? Standard committee cares about API stability a lot, so that's not a worry. Although some want a new version of the API that uses std::expected. ## Parallel STL algorithms We could allow parallel execution tags in our API to let users ask for use of parallel algorithms. But what are the places in Qt API that actually need these? More data analysis stuff (if developed) would find it helpful. But often users get to choose their own algorithms and so can use parallel algorithms without our containers needing to know about it. If a parallel STL implementation is not available, falling back to single-threaded implementation is always an option. So support could be utilized only when available and not demanded from all platforms. Or the platfrom support can be a shim that still always processes everything without parallelism. ##
Re: [Development] RFC: Defaulting to or enforcing UTF-8 locales on Unix systems
On Sunday, 17 November 2019 01:55:32 CET Thiago Macieira wrote: > I don't know why QTextCodec is being removed. I don't remember any decisions > in prior QtCS or this mailing list about removing it. We definitely > discussed removing the CJK codecs and their big tables and that can still > be done, with no effect in the API, since QTextCodec is backed by ICU's > ucnv. We may have discussed removing it, but I don't remember a firm > decision. And even if it is firm, after looking at the consequences of > doing so, we may want to reverse our decision. Update: after talking to Lars during QtCS, he said that he thinks the QTextCodec API is poorly designed and should be replaced. I agree. But that doesn't mean we need to remove the *functionality*, just deprecate the API. I'll bring this up during the QtCore session tomorrow to see if we want to invest time creating a new API, hopefully for 5.15, so code can begin porting before the 6.0 time. That way, we could move QTextCodec out of QtCore. > 1) QTextCodec in the API > I think we cannot do without it, it'll have to stay in one way or another. > So the question reduces to whether it should stay in QtCore or be moved to > another library. Given the QXmlStreamReader problem above, it's probably > best to keep it in QtCore, actually. > > QTextCodec has some API limitations but they can be fixed. It's not > necessary for us to remove it: it's not *that* broken. This is now TBD, depending on finding a good design and whether it can be done incrementally in QTextCodec. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Notes from "QtGUI, RHI, 3D" session at Qt Contributors Summit 2019
Hi all, Notes from the QtGui, RHI, 3D session are available at https://wiki.qt.io/Qt_Contributor_Summit_2019_-_QtGui_RHI_3D Best regards, Laszlo ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Notes from "Releasing" session in QtCon19
Hi, I took the notes for the "Releasing" Session we just had at the Qt Contributor Summit 2019: https://wiki.qt.io/Qt_Contributor_Summit_2019_-_Releasing_Notes High level summary: * The Releasing Dashboard [1] in JIRA provides a good overview of upcoming releases, Qt Creator releases will be added there, too. * We should list all contributors of a release in the ChangeLog (AP Jani Heikkinen) * Let's encourage people to help editing ChangeLogs (gerrit in-editing) (AP everyone) * Next time for release meeting (cancellations) will be (also) announced in IRC channel topic (AP Jani Heikkinen) Greetings from Berlin! Kai [1]: https://bugreports.qt.io/secure/Dashboard.jspa?selectPageId=15911 -- Kai Köhne, Director R | The Qt Company The Qt Company GmbH, Erich-Thilo-Straße 10, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Session notes for "Code Review: Sharing the load" and follow-up session
Hi Nils,
thanks for the summary.
I have two additions:
* Reactivate the QDoc bot to sanity check the docs
* Improve the output of sanity bot, especially for new users:
https://bugreports.qt.io/browse/QTQAINFRA-1478
Best regards,
Andre
Am Mittwoch, 20. November 2019 schrieb Nils Jeisecke via Development:
> Hi list,
>
> these are my notes for "Code Review: Sharing the load" session, extended
> by "Improve the contributor experience of the Qt project"
>
> ---
>
> * Situation: Many reviews in queue for long time (forever?)
> * Android: They have a button: Find "Maintainers" (Plugin for Gerrit)
> * Thiago: Would solve the first 15 Minutes for Contributors, not enough
> * Improve the culture, appreciate the effort ("Thank you!")
> * Get more people on-board as reviewers (not as approvers yet)
> * Idea: Should not be +1 and +1, should be "Thumbs up" and "Tick!"
> * Some reviewers don't understand the implication of "+1" (two "+1" !=
> "+2")
>
> * What does a good patch looks like?
> * breaking patch up into multiple patches
> * Is the documentation really good enough (opinions vary)
>
> * Ask contributors whose changes have just been review to review others
> (sometimes happens)
>
> * Gerrit
> * Sanity bot is good
> * Revive early warning bot!
> * Should changes only be approved after tests has run on CI?
> * Can we get a "small CI" run (just Linux, "does it build?")
> * Should the bot automatically run tests if tests have been changed?
> * Should the bot automatically give a warning if tests have not been
> added (excluding doc only changes)?
> * "Auto defer" bot is currently not active, would be useful to automatically
> defer patches where contributor did not response to requests.
> * Automatically stage when change is approved? Faster turnaround time.
> * Mail (monthly?) reports to maintainers (or others?) (based on gerrit
> dashboard config?): "N Changes approved, but not staged? Link to staging
> page", List per module?
> * Let's try it and see how it works out
>
> * Gerrit Features unused right now
> * Attach labels
> * Bot could apply hashtags ("wants adoption", "stage-me")
> * Has a feature to make clazy automatically appply improvements to the
> change ("contributor has to click a button")
>
> * Public Community Feedback does not exist
> * Alex: Use Thiago's script to highlight new contributions (Grafana?)?
> "Welcome new contributor!" for blog post (Like KDE does)?
>
> ---
>
> Follow-up session extensions (lots of overlapping topics)
>
> * Give contributor feedback
> * Bot should say: "Welcome, Thanks for your first contribution"
> * Monthly blog post advertising external contributors?
> * Send out physical awards? T-Shirts, "Thank you" letter, ...?
>
> * Make contributing easier
> * Put contributor documentation into Qt's documentation ("Gettings
> started")?
> * Link freenode IRC Web-Backend to simplify access to IRC for new
> contributors
> * Use Qt account profile to setup everything needed for contributing (ssh
> keys, CLA check, ...)
> * Adapt github workflow (Checklist "Auto test done", "Documentation done",
> ...)
>
> * Triage bugs
> * Add Jira label ("for juniors")?
>
> * Community
> * Missing Community manager (Consent: Yes, it's needed)
> * Missing "qt-project" entity, kind of a foundation? Funding?
> * Redefine: What is the qt-project?
>
> * Activating new contributors
> * Communication of Qt (company) targets companies, not community (qt.org =>
> qt.io => sales)
> * Microsoft pushes its stuff to universities, why not Qt (or qt-project?)
> * Qt project needs a proper homepage. With nice, contemporary Howtos, ...
>
> ---
>
> Nils
>
--
Von meinem Jolla gesendet
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
[Development] Session notes for "Code Review: Sharing the load" and follow-up session
Hi list,
these are my notes for "Code Review: Sharing the load" session, extended
by "Improve the contributor experience of the Qt project"
---
* Situation: Many reviews in queue for long time (forever?)
* Android: They have a button: Find "Maintainers" (Plugin for Gerrit)
* Thiago: Would solve the first 15 Minutes for Contributors, not enough
* Improve the culture, appreciate the effort ("Thank you!")
* Get more people on-board as reviewers (not as approvers yet)
* Idea: Should not be +1 and +1, should be "Thumbs up" and "Tick!"
* Some reviewers don't understand the implication of "+1" (two "+1" != "+2")
* What does a good patch looks like?
* breaking patch up into multiple patches
* Is the documentation really good enough (opinions vary)
* Ask contributors whose changes have just been review to review others
(sometimes happens)
* Gerrit
* Sanity bot is good
* Revive early warning bot!
* Should changes only be approved after tests has run on CI?
* Can we get a "small CI" run (just Linux, "does it build?")
* Should the bot automatically run tests if tests have been changed?
* Should the bot automatically give a warning if tests have not been added
(excluding doc only changes)?
* "Auto defer" bot is currently not active, would be useful to automatically
defer patches where contributor did not response to requests.
* Automatically stage when change is approved? Faster turnaround time.
* Mail (monthly?) reports to maintainers (or others?) (based on gerrit dashboard config?): "N Changes approved, but not staged? Link to staging page", List per module?
* Let's try it and see how it works out
* Gerrit Features unused right now
* Attach labels
* Bot could apply hashtags ("wants adoption", "stage-me")
* Has a feature to make clazy automatically appply improvements to the change
("contributor has to click a button")
* Public Community Feedback does not exist
* Alex: Use Thiago's script to highlight new contributions (Grafana?)? "Welcome new
contributor!" for blog post (Like KDE does)?
---
Follow-up session extensions (lots of overlapping topics)
* Give contributor feedback
* Bot should say: "Welcome, Thanks for your first contribution"
* Monthly blog post advertising external contributors?
* Send out physical awards? T-Shirts, "Thank you" letter, ...?
* Make contributing easier
* Put contributor documentation into Qt's documentation ("Gettings started")?
* Link freenode IRC Web-Backend to simplify access to IRC for new contributors
* Use Qt account profile to setup everything needed for contributing (ssh
keys, CLA check, ...)
* Adapt github workflow (Checklist "Auto test done", "Documentation done", ...)
* Triage bugs
* Add Jira label ("for juniors")?
* Community
* Missing Community manager (Consent: Yes, it's needed)
* Missing "qt-project" entity, kind of a foundation? Funding?
* Redefine: What is the qt-project?
* Activating new contributors
* Communication of Qt (company) targets companies, not community (qt.org => qt.io
=> sales)
* Microsoft pushes its stuff to universities, why not Qt (or qt-project?)
* Qt project needs a proper homepage. With nice, contemporary Howtos, ...
---
Nils
signature.asc
Description: PGP signature
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
