In the discussion of T2802 (http://mitk.org/wiki/ChangeRequests/2802) I found the design of mitk::ProgressBar and its Qt implementation had an unnecessary complicated design.

What actuallly happens:

The Qt implementation of mitk::ProgressBar::Progress(..) can crash when unknowingly called from a thread.

Expected behaviour:

The implementation should not crash. Implementors of filters should not need to predict whether filters will be called from a thread or not.

Cause of the bug

mitk::ProgressBar can be used from threads. The methods "AddStepsToDo" and "Progress" take a bool parameter "callFromThread" for this purpose.

When the parameter "callFromThread" is set, the event which leads to an update of the Qt GUI (visible progress bar) is only posted to the Qt event loop -- i.e. the progress bar update only happens when Qt processes the event loop, which is always from the GUI thread.

Currently, the default value of callFromThread is false.

Proposed solution:

It is the implementation's responsibility to correctly handle calling from threads. In the Qt case this can be handled using a signal/slot connection for each method that is called by clients.

By changing the mentioned responsibility, the aforementioned parameter "callFromThread" can be removed.

All calling classes that used to set this parameter explicitly must be changed and omit the parameter.