<div class="gmail_quote">On Thu, Sep 23, 2010 at 9:01 PM, Boudewijn Rempt <span dir="ltr"><<a href="mailto:boud@valdyas.org">boud@valdyas.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">On Tuesday 21 September 2010, Dmitry Kazakov wrote:<br>
</div><div class="im">> > And there would still be a clash with the paint tool, since I don't think<br>
> > that its actions should be mixed in the queue with the long running actions.<br>
> > And it might still be better usability to disallow starting a new gradient<br>
> > while the old one is running, for instance.<br>
> ><br>
><br>
> I think there is nothing bad in adding all the tools and actions to the same<br>
> queue in case the queue has good barrier abilities.<br>
<br>
</div>Well, I do share Sven's main concern: freehand painting should be blocked until the queue is free. That really is the big issue with queuing, and I'm not sure how to solve that. Are the barriers you mention a way towards a solution?<br>
</blockquote><div><br>I think we could solve that by mixing both concepts. I propose the following:<br><br>We introduce a new class KisNodeActionScheduler that could be in KisImage or similar central place. All node actions would have to go through this class. The scheduler would manage the node queues and distribute node actions to the queues. The class is protected by a mutex, so we don't get race conditions there.<br>
<br>For adding job I suggest that node actions can added with some type parameter. The action can either be marked as "queue" or "blocking" (names are need a better choice). In case of "queue" the scheduler simply adds the job to the end of queue. The "blocking" type would be used by interactive tools. In that case the scheduler only add the action if the queue is empty.<br>
The method that adds the action returns the result of that, so that the tools will be informed if the action they wanted to add wasn't accepted and don't proceed.<br><br>I think cancel and undo is tricky. I think we should limit cancel to the last action that was added, because otherwise we could get into some crazy cases where we cancel some action in the middle of a queue. Undo commands need to be added in the order that the user added the action. Currently we add undo commands after the processing is finished which means that the order of the undo commands depends on the time the actions need to process.<br>
<br>The scheduler should also be able to pause action. This isn't that urgent, but should be added in future releases. Imagine a case where you have started a very computing intense filter on one layer and want to paint on another layer. In that case the scheduler would pause the filter while you are painting to keep it snappy.<br>
<br>What do you think?<br></div></div>