On 3 May 2023, at 15:21, Giuseppe D'Angelo via Development <development@qt-project.org> wrote:
Il 02/05/23 12:34, Volker Hilsheimer via Development ha scritto: What started as an attempt to provide a few building blocks for making it easier to build asynchronous APIs taking any kind of callable (like QTimer::singleShot or QHostInfo::lookupHost) [1] has turned into a bit of a longer journey to the core. [1]https://codereview.qt-project.org/c/qt/qtbase/+/470341 [2]https://codereview.qt-project.org/c/qt/qtbase/+/475168 A general problem here is whether we can provide this infrastructure as a public API. If I have a class of mine and want to provide convenience for connecting to slots/callables, how do I do it without using private APIs? In Qt 4 days that was a simple: void foo(..., QObject *receiver, const char *slot); But it's not so simple/possible any more with the PMF syntax. Indeed, if we assume that functions-taking-callables are a part of the tools we want to use to make more Qt APIs asynchronous, then it’s important that we enable other Qt-based libraries to build such APIs as well. One aspect to think about is then to make sure that the respective APIs fail early and with good error messages when called with incompatible functors etc. For that, I’d rather add a library of concepts than making our current predicates and private helpers public. So yes! Ultimately I’d like to provide the required building-blocks as public APIs. These changes are a step into that direction, I hope. The plumbing required to then correctly make the call to the callable in the right thread is still significant, but see also https://codereview.qt-project.org/c/qt/qtbase/+/469799 for another small step, and Fabian has some ideas about how we could inject a QMetaCallEvent into the event loop of the correct thread (without having to create a temporary receiver QObject). Volker
-- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
