Usage of setCurrentNodeLocked()

[Dmitry Kazakov]

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

I think, to be more productive we can discuss and criticize some particular
model of this subsystem. We can use a draft that i proposed it the
beginning:

http://dimula73.narod.ru/ToolJobsQueue.xmi


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

May i ask a question? ;) What the tool is supposed to do if it got a reply
that it's stroke has *not* been added to the queue? Just drop it or what?

see "Rejected Stroke Case" diagram.


Speaking truly I'm against dropping any actions made by the user. That is
the way Gimp works. If you want to paint two gradients and you do it fast
enough to do the second stroke before the first has finished it's
calculation, the second one will be dropped. I think it is the worst thing
we can suggest for a user =)

The case when two types of strokes (e.g. gradient and brush) are mixed in
the queue. I think there is nothing bad in it. The model i proposed will not
start execution of a brush stroke, before the stroke of the gradient is
finished.

see "Two types of strokes" diagram.


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

Well, the queue guarantees that two different strokes will never be
executing simultaneously. So the problem of undo is not actual here, i
guess.

Cancel, yes, we can do it in two different ways:
1) Esc-key cancels all the contents of the queue.
2) Esc-key removes the last stroke from the queue. So to clear the queue,
you will have to press Esc several times.

Actually, i don't know which variant is better.


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

I think this will be very weird "feature" from interactions design point of
view. Noone will pause any actions manually, while they are painting
something. More than that, it is not always possible (simply technically) to
pause an action and start working on the same image. The thing that is
possible, i think, is to have priorities of the tools and sort the queue,
but it can lead to really weird and unexpected results from the UI point of
view.


-- 
Dmitry Kazakov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kimageshop/attachments/20100924/220e139d/attachment.htm