Usage of setCurrentNodeLocked()

[Sven Langkamp]

On Thu, Sep 23, 2010 at 9:01 PM, Boudewijn Rempt <boud at valdyas.org> wrote:

> On Tuesday 21 September 2010, Dmitry Kazakov wrote:
> > > And there would still be a clash with the paint tool, since I don't
> think
> > > that its actions should be mixed in the queue with the long running
> actions.
> > > And it might still be better usability to disallow starting a new
> gradient
> > > while the old one is running, for instance.
> > >
> >
> > I think there is nothing bad in adding all the tools and actions to the
> same
> > queue in case the queue has good barrier abilities.
>
> 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?
>

I think we could solve that by mixing both concepts. I propose the
following:

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.

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.
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.

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.

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.

What do you think?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kimageshop/attachments/20100924/18ce5a07/attachment-0001.htm