Hi, Looking at it with the “Qt Creator” hat on, i.e. with the mindset of “could we replace what we do in Qt Creator with our extension of QtConcurrent". (http://code.qt.io/cgit/qt-creator/qt-creator.git/tree/src/libs/utils/runextensions.h adds the convenience and actual runnable based around QFuture and QFutureInterface.) I suppose this is a very UI-interaction focused, and high-level view on things ;) but it is something that the QFuture/QFutureInterface/QFutureWatcher API supports.
1) I think the chaining/promises style is an improvement to the need to always use QFutureWatcher. We more often need to carry a QFutureWatcher member around than I like (even with a helper function Utils::onResultReady, the moment you need to handle various signals you’ll want to stick to a single QFutureWatcher) 2) We use QFuture/QFutureInterface for a generic progress UI. Basically you tell a central progress UI manager about your QFuture, and that shows a progress bar for it, including a cancel button. What about multiple “subscribers” to a task? The progress UI needs to act on progress info, and finished / success status changes. On a glance I didn’t see if that is possible with your API. I didn’t see cancel functionality in your work, do you have thoughts on this? The implementation for progress seems to be a bit awkward in comparison to QFutureInterface, and doesn’t seem to be separate from the result type? Progress can be pretty separate from actual result producing, i.e. a file system search will be able to provide very fine grained progress information, but might only report a handful of results. Another thing that QtConcurrent handles for us, it to guard against “too much progress reporting”. I.e. if a loop from 1 to 1000000 reports every single step as progress, this would block the UI/main thread with progress updating. QtConcurrent makes sure that actual progress reporting to the receiving thread only happens in “sensible” intervals. One nice thing about QFuture/QFutureInterface is that one doesn’t actually need to create an _actual_ async task to use the same functionality. We use that at a few places for showing progress for things that are not actually running in a thread, but wait for other asynchronous tasks to finish (e.g. QProcess). But that’s just a convenience that avoids having a separate API for it. 3) Reporting intermediate results is something that we heavily use for things like e.g. the search functionality. While the search is running, you want the UI to already present what was found so far. Br, Eike > On 11. Feb 2019, at 12:49, Juan Gonzalez Burgos <juangbur...@gmail.com> wrote: > > Hi guys, > > Sorry to bother you with yet another promise/deferred library for Qt. I am > looking for feedback. > > https://github.com/juangburgos/QDeferred > > Thanks. > _______________________________________________ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development -- Eike Ziller Principal Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin eike.zil...@qt.io http://qt.io 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
