Progress notification

[Boudewijn Rempt]

Currently, we use an event based progress architecture, with vestiges of the 
old publish/subscribe architecture. This architecture has a couple of big 
problems (for the sake of discussion, an action is something like a filter 
process() call or a visitor call):

* 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

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

There are three possible mechanisms for notifying the view of progress that I 
can see:

* pub/sub
* sending events
* emitting signals

pub/sub is very heavy weight; events have as a disadvantage that we need a 
unique event id for our custom events (which may clash) and for signals/slots 
we need QObjects.

I'm not sure how to progress: we want to look at ThreadWeaver and Thomas' 
threadable actions framework before doing anything. Other ideas?

-- 
Boudewijn Rempt 
http://www.valdyas.org/fading/index.cgi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kimageshop/attachments/20061020/4bd15014/attachment.pgp