D8199: Allow abortion of starting another NativeAppJob

Christoph Roick noreply at phabricator.kde.org
Mon Oct 9 23:13:55 UTC 2017


croick added a comment.


  In https://phabricator.kde.org/D8199#153863, @mwolff wrote:
  
  > looking at the old code, I wonder why it did what it did... Most notably, it refetched the current jobs after the message box. This looks intentional and is now gone. I mean sure, while a dialog is shown, anything could happen, including running another job... Do we need to take care of this? Does anyone remember why it was done in this way? Does the git history show up anything?
  
  
  I introduced that restart of the whole loop, when fixing the unit test behaviour (https://phabricator.kde.org/D6593). While the bug was still present, three instances of the same process could be launched in the background, which revealed what could go wrong with that dialog. That's not happening any longer and even if it does: The use of QPointer guards against access to deleted jobs, I just didn't think of that solution.
  
  > If we don't need that anymore, can we get rid of the loop altogether? I mean either we want to kill all jobs, or none. Showing one dialog per job is confusing as there is not indication which job we are going to kill out of multiple ones...
  
  There only is a job name and the jobs in RunController::currentJobs() have no particular order, so showing a counter or so wouldn't help. Probably your suggestion is the best solution. If the user wants to kill a specific job, he will probably do that manually...

REPOSITORY
  R32 KDevelop

REVISION DETAIL
  https://phabricator.kde.org/D8199

To: croick, #kdevelop, mwolff
Cc: mwolff, kdevelop-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20171009/8ca53b8e/attachment.html>


More information about the KDevelop-devel mailing list