Usage of setCurrentNodeLocked()

[Dmitry Kazakov]

> There are non-interactive actions like filters and interactive action like
> freehand. While the first can be queued the later can not. Gradient is
> somewhere between both.
>
> For me a freehand action is everything between initPaint and endPaint. And
> in the freehand to I expect to see what is going on. Now if there is a
> filter running on the node and put a freehand action behind the filter in
> the queue you don't see what you are painting.
>

So you do suggest to drop a user's stroke, don' t you?
Btw, when you are painting with a big slow brush, you don't see what you are
painting as well. Maybe, we should drop such a stroke as well? ;)

The only usecase for such a blocking, i think, is mixing some global image
commands with tools, e.g. mixing Resize Image and Freehand Tool. So Resize
Image should be blocking. But no blocking should happen for pure tools. We
should respect what the user has done, and don't throw it away.



> Not exactly, I'm wondering if we are talking about the same thing. There is
> one queue per node which means that several actions are executed at the same
> time. There could be a filter running on layer 1, while you are painting on
> layer 2. So different actions can finish at the same time, so you need to
> check the order in which they are added to the undo stack.
>

Ermm.. do you see any usecase for making a separate queue for every node?
Speaking truly, i don't see any. My motivation:
1) It is really irritating, when you are trying to paint and your image is
constantly flickering. So in most cases a human will wait until everything
calms down and continues to paint after that. So the order of updates is not
very important.
2) I don't think that the workflow of an artist is parallelizable. That
means, you have to see what you've already done, and only then go on
working.

How i see this workflow:
* In most cases the user waits until his previous action has been finished.
He waits voluntary, without any compulsion from the system. He just wants to
see what he has done.
* In some cases he may decide to do several strokes one right after the
first one. E.g. he wants to paint a dashed line. He doesn't want to wait for
every stroke, he just moves his stylus. If we decide to drop his strokes
(because the brush he uses is really slow), he'll be really disappointed ;)

Here we have to care for several queue too. Scale image would start several
> seperate node actions in different node queues. If you want to cancel that
> you have to cancel every node action which might be already applied.
>

Sounds weird.

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.
>>
>
> This would be done automatically. With the example from above the brush
> stoke would get choppy because the CPU is busy processing the filter.
> Pausing an action is a bit difficult, but at least you could stop other
> queues.
>

Well, again. I don't see any reason in painting on not-fully updated images
except dashed-line example. Humans are not machines. More than that, it is
really tricky process to switch to another layer while the previous tool
hasn't finished yet, look at not-finished image, decide what you are going
to paint here and paint it. And all that should be done while your CPU is
under 100% load.





-- 
Dmitry Kazakov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kimageshop/attachments/20100925/3ca8b06a/attachment-0001.htm