Progress update and action cancel architecture

[Boudewijn Rempt]

Currently, Krita handles progress updates & cancelling of long actions through 
a signals and slots. There's also quite a bit of close coupling, with the 
progress subject registering itself with the progress display label. 

This gives problems with threading: if I start four threads and they all want 
to update the progress label, we're in for a rude shock. The progress label 
is broken anyway because it uses processEvents(), which guarantees crashes, 
especially if users are scaling in one view and trying to work in another.

I'm groping for an architecture that will work here and that will give us a 
clean path towards locking just one view instead of all views when a 
long-running process runs.

I've got some ideas, but as you can see, there's one problem that I'm not sure 
how to solve (except by rewriting Krita to never act directly on input, but 
add every command the user gives to a queue that is emptied as soon as 
possible):

pseudo-code ahead alert:

KisThread : QThread {

	// Canceled value is read by the subclass
	void cancel() { m_canceled = true; } 

	boolean isCanceled();

private:
	bool m_canceled;
}

LengthyThreads : KisThread 
{
	
	void run() {
		while (!isCanceled()) {
			doStuff();
			qApp::postEvent(KisProgressInterface, new UpdateEvent(percentDone));
		}
	}
}

KisSomeClass : KisProgressSubject {

void lengthyOp(KisProgressInterface kpi ) {
	kpi.initialize("LengthyOp", this, MAX_THREADS);

	for (int i = 0; i < MAX_THREADS; ++i) {
		KisThread t = new LengthyThread();
		t.start();
		m_treads.append(t);
	}
	// This is the tricky bit: if we wait for all threads, the events are never
	// sent or processed, because we're blocking the gui thread by waiting for
	// the worker thread. We want to block on all user input, except for the 
	// cancel button, or, ideally, find a way to store new commands for this
	// in a queue and handle them later.
}

void cancel() {
	for all threads in m_threads: thread->cancel();
}
}
-- 
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: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kimageshop/attachments/20051227/79af3d6a/attachment.pgp