Progress notification

[Cyrille Berger]

> * not thread-safe
> * cannot handle more than one progressing action at the same time
> * uses processEvents (which is dangerous)
> * costs us quite a bit of cpu
actually the cpu cost mostly came from the repaint of the progress bar. I said 
came, because sebastian has made a patch in 1.6 that have make the whole 
process to be a drop water in the sea, for the gaussian blur filter it's less 
than 1% of the time, and for the invert filter, it's lost in the noise (same 
for more expensive filter like cimg).

That's said, all other points are valid.


> We need to replace it, therefore. The list of problems is very nearly the
> list of requirements for the replacement:
>
> * threadsafe (should be able to handle updates from different threads
> within the same action and still show a continuous progress towards 100%) *
> be able to handle more than one concurrent action
> * be safe
> * be cancelable
> * non-modal
> * function for the preview of filters, too
> * be fast
> * be really easy to use
* algorithms must be able to call one other and the correct progress should be 
display, for instance, the unsharp mask is composed of two operations, first 
bluring, then a diff between the blured image and the original one. The 
progress bar should at least go from 0 to 50% for the first operation, and 
from 50% to 100% when doing the second operation (actually it's more 0 to 80% 
and 80% to 100%, but you understand what I mean).

-- 
--- Cyrille Berger ---