> On 26 May 2025, at 15:56, Jaroslaw Kobus via Development > <development@qt-project.org> wrote: > > Hi All, > > I'd like to start a broader discussion about including TaskTree in Qt and > making it a public API. > > TaskTree is a solution broadly used in QtCreator in hundreds of places, > for convenient managing of sets of asynchronous tasks of various types, > including running processes, functions in separate threads, network > communication, and much more. > The solution is easily extensible in terms of new task types. > It's a matured solution, with a 2.5 years of lifetime already. > > TaskTree is already a part of Qt, but used just in one place, and privately > so far (qtbase/src/assets/downloader). > > The main page for the TaskTree is here: https://wiki.qt.io/TaskTree > > According to https://bugreports.qt.io/browse/QTBUG-131142 > I stared a work that introduces a new Tasking module in qtbase > (qtbase/src/tasking). > The patch is here: https://codereview.qt-project.org/c/qt/qtbase/+/645458 > > I'm not sure what is the official process of adding new module to qtbase, > thus I'm posting it here, counting for more feedback > and a possible agreement for this new module to be a part of Qt. > > I would be very glad for any further comments and opinions on this topic. > All reviews of the mentioned patch are of course very welcome and appreciated. > > Thanks in advance and best regards, > > Jarek
Hi Jarek, Thanks for pushing this forward, after several discussions at Qt Contributors Summits over the past years. For reference: - 2023: https://wiki.qt.io/TaskTree_CS23 - 2024: https://wiki.qt.io/QtCS2024_TaskTree Two thoughts: - how does TaskTree fit into a C++26 future with sender/receiver - what’s the advantage of having TaskTree/QtTasking in qtbase, vs a dedicated repository These two are somewhat related: if TaskTree and sender/receiver overlap, and the former is to some degree made obsolete by the latter, then having it in qtbase might not be optimal. But even if they don’t: should we increase the amount of stuff that lives in qtbase? qtbase is a necessary artefact due to the entanglement of certain modules; we don’t have it by design (various opinions about mono-repo aside). Adding more modules to it seems suboptimal, unless we plan to use QtTasking within any of the existing qtbase modules (in which case it would be good to know what the plans are to do so). Getting changes into qtbase is … no joy. The asset-downloader using it might be one reason, but then looking at how we are using that right now, perhaps it was suboptimal to add that one to qtbase; the only example that uses that (short of the example showing how to use the downloader, which is in qtdeclarative…) is the car-configurator, which is in qtdoc. So if there is no other good reason to have QtTasking in qtbase, then it might be more sensible to move the asset downloader helper into qtdoc. Examples that come with such large assets that we need to download them explicitly would then have to live in qtdoc as well - which is perhaps ok. Volker -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
