Allow all operations except the content indexer to work when suspended. Allow manually resuming file content indexing while on battery. Allow some operations to run in parallel.
Split-up scheduler overhaul patchset.
Commits are squashed on arc land anyway, but the branch can be manually pushed keeping the separate patches. If you mean separated into different reviews, I don't think it's unclear why there are small changes to code related to the scheduler, or why it might be advantageous to separate these into different reviews.
Is there any practical reason why a simple arc land wouldn't suffice here?
Because pushing independent stuff in a single commit just sucks for the reviewer, and it sucks if you want to understand the git history later.
You are changing 5 different things in your patches. I can not see which changed source line relates to which change.
For future reference, the preferred method to implement a multi-commit patch chain is with multiple Phabricator revisions. See https://community.kde.org/Infrastructure/Phabricator#If_the_patches_are_all_for_the_same_project
Split this into independent changes.
Add add comprehensive description to the summary - a bug reference is insufficient.
You sneak in a unmentioned and significant change - you allow to run several indexer tasks to run in parallel!
Whats that supposed to do (I have an idea, but thats ugly ...)
Make this a QFlags ...
This starts a QRunnable at a negative priority (in this case the negative integer value for NewFiles) and then calls runnableStarted(NewFiles) with the enum of the started runnable.
There is no cast from int to enum anywhere here. There is a cast fron enum to int, to a negative integer used to set the QRunnable thread priority.
Exporting the storage object is not part of this patchset.
If you don't understand the code, do not change it.
This is not about avoiding to be scheduled, but missing the schedule signal.
You are mixing a ton of different things here, clean it up!