In kjobwidgets we have KWidgetJobTracker and KUiServerJobTracker.
For proper handling of situations where there is no kuiserver job tracker, there's a KDynamicJobTracker but it lives in KIO.

The biggest issue with KUiServerJobTracker is that it does everything as blocking DBus calls.

Moreover, there's a grace period until a job is actually shown to the user to avoid spamming them with short-lived stat jobs and what not. However, it still registers the job on the job tracker, causing multiple blocking DBus calls, for no user-visible reason.

The grace period can also be undesirable, when for instance receiving a file from your phone. You always want the confirmation that the file was received and easy access to it.

Furthermore, the current kuiserver API is based on loads of method calls. This is probably for performance but caused major headaches when adding new features (e.g. setError was added later) as it can cause discrepancies between the DBus XML used and installed by Frameworks and the one used on the server side. I already added a JobViewServerV2/JobViewV3 interface in Plasma which is mostly based on a variant map. This makes it extensible but also allows batching changes (e.g. often number of files copied, number of bytes copied, file path, overall percentage change in unison) into a single call.

My suggestions:

• Make KUiServerJobTracker use async DBus calls. This requires buffering any pending state changes in the class until the job view is registered and/or changes sent out and processed.
• Port it to use the new JobViewServerV2 API
• Do the registration grace period on the application side, i.e don't actually request a job view until the 500ms grace period has run out. (Perhaps still do if it fails within the period, so an error is always communicated?)
• Introduce an ImmediateProgressInfo (naming suggestions welcome) flag similar to HideProgressInfo which then immediately shows progress in case of e.g. download jobs or file receive jobs where you're likely to actually want to use the file after it's done.
• (nice to have) Move the dynamic job tracker into kjobwidgets so it becomes a first-class citizen job tracker preferred to be used over the others. This tracker could then also be used to check whether to use JobViewServerV1 or V2 for compat.