<div class="gmail_quote">On Tue, Sep 21, 2010 at 8:53 PM, Cyrille Berger <span dir="ltr"><<a href="mailto:cberger@cberger.net">cberger@cberger.net</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 Sunday 19 September 2010, Boudewijn Rempt wrote:<br>
> On Sunday 19 September 2010, Dmitry Kazakov wrote:<br>
> > I think adding parameters is the worst thing that we can do here =(<br>
><br>
> Maybe it would be better to bite the bullet & not use the locked system to<br>
> hint for updates, but add a signal updated() to KisBaseNode that can be<br>
> emitted by tools when they are done.<br>
</div>Yes I quite agree. Sounds like it is a workaround, that abuse an other<br>
workaround. The reason systemLock was added is because we didn't had a system<br>
to queue actions.<br>
<br>
This is why I also agree with Dmitry that systemLock should disappear one day.<br>
<br>
It should be replaced by a list of action that need to be applied on a node,<br>
and in a thread, the first action of that list is applied in thread, and tools<br>
only add new actions to that list. And some tools (or paintops) that needs an<br>
empty list (think the duplicate op) would simply be locked or prevented to<br>
paint (and show the "blocked" cursor).<br>
<br>
We basically have all the bricks to implement this with the ThreadApplicator<br>
framework, and the action recorder to provide the actions.<br></blockquote><div><br>The problem I'm seeing with this is that the queue wouldn't just buffer for a short time but is could take several seconds.<br>So you could start a filter that takes several seconds and while the filter is running paint something and start another filter. Then Krita would process your filter and show the outcome. You would basically paint blind for some time. I don't know about you, but I can't predict what my final painting looks like ;)<br>
</div></div>