It can happen that a plugin calls finish() in a slot which normally would be dispatched before the timeout
but due to high system load the slot is invoked only after the timeout. This in turn would cause Qt to also queue up
this timeout slot and by the time the system processes slots, the plugin comes in first and we'd fire an aborted()
signal in the plugin after it called finish(), potentially badly breaking the plugin as a plugin developer would not
expect this to happen. So we'll have to verify here that the plugin did not finish() by now before aborting.
This gives plugin developers a chance to finish() an info on their
own in an aborted() handler and set a custom error code and
displayMessage without causing a "finishing an already finished object"
warning.
Bad plugin implementations might call finish() more than once
which is not expected by receivers of the finished() signal and
may cause weird side effects.
Simon Stürz
jenkins
Michael Zanetti