Don't block waiting for the server to register the job, especially since it is typically only shown after 500ms anyway.
I also don't see how the job could be deleted from under us inside that function, so I removed all those early returns,
Details
Details
- Reviewers
dfaure davidedmundson - Group Reviewers
Frameworks
Froze the server, app didn't block waiting in the register call anymore.
Let the job finish and then unfroze the app, got a reply but it found the job already deleted and didn't do anything and didn't crash.
Diff Detail
Diff Detail
- Repository
- R288 KJobWidgets
- Lint
Lint Skipped - Unit
Unit Tests Skipped
Comment Actions
- When reply comes in after job already finished, call terminate on the jobview to end it gracefully
Comment Actions
However now it obviously misses the first calls to set message and what not because the job view doesn't yet exist there...
Comment Actions
I've got a jobviewv2 thing in the works which is qvariantmap-based so it can easily queue any changes and send them out once registered. I think jobviewv1 should just stay as is and be phased out eventually, cf. T12574