dfaure requested changes to this revision. dfaure added a comment. This revision now requires changes to proceed.
I don't think it's KJob's job (haha) to be responsible for compressing change notifications, which is basically the use case you're mentioning. This can be done with a QTimer and an associate container of pending changes, on the application side. Such a solution is much more flexible because you can add the data you need (for fast lookups, for more precise decision making etc.) in that container, rather than having to introspect not-started-yet jobs. Not to mention the issue with in-progress jobs. The pipeline here is KDirWatch ---> notification compression ---> actual operations that *should* be triggered = KJob. Misusing KJob as a holder for notification compression seems wrong to me, there are better data structures for that. -1 from me. REPOSITORY R244 KCoreAddons REVISION DETAIL https://phabricator.kde.org/D8999 To: rjvbb, dfaure Cc: apol, anthonyfieroni, #frameworks
