<br><br><div class="gmail_quote">On Mon, May 7, 2012 at 6:19 AM, Sven Langkamp <span dir="ltr"><<a href="mailto:sven.langkamp@gmail.com" target="_blank">sven.langkamp@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote"><br><div>Explanation:<br><br>Command: A command is contains basically two things: 1) an id string to identify the command 2) a KisPropertiesConfiguration that contains the parameters<br><br>Command Widget: That's the ui for the command like the current dialog, but closer the filter widgets (and paintop options). It writes the input of the UI into the KisPropertiesConfiguration like we do for filter. Then the command is send to the command switch.<br>

<br>Command switch: This is like a normal network switch. A command comes in and the switch looks at the id and passes it to the command runner that is associated with the id of the command. It's also a big registry for command runners, which are registered by Krita or plugins.<br>

<br>Command runner: The class or plugin that executes the command.<br></div></div></blockquote><div><br>Actualy, this fits very well into the idea of the strokes framework. We just need to expand it to cover the usecase of recording as well, because this usecase was taken into account during for its design. [1]<br>
<br>The "command switch" may be a couple of a stroke strategy factory and the registry where it is stored, while the "command runner" is the stroke framework itself.<br><br>To implement the recording based on strokes framework we just need to implement 3+3 factory classes for the strokes we have and for their stroke jobs and write toXML/fromXML methods for the stroke strategies. It's not too difficult. After that the update scheduler would be able to record everything we do.<br>
<br>Although there are two complications. <br><br>The first one is related to the fact that we need to save the contents of QUndoCommand somehow.<br><br>The second one is related to the complex tasks like "Resize Image". Currently, to do this job we use KisProcessingApplicator, which creates all the strokes and stroke jobs for us and eases our lives. This is, of course, cool but the problem is that it creates the jobs (and QUndoCommands) asynchronously in the context of the caller thread. It means that it also fetches the data about the image asynchronously, which may be wrong because some strokes may be changing the image concurrently [2].<br>
<br><br>As a solution for the first  problem we can just add toXML/fromXML methods to all the commands we have and make KisStrokeStrategyUndoCommandBased and its factory fetch this information. This appreach allows us to port all the actions to strokes very easily, but it doesn't handle the first problem in any way. More than that, the saved actions may become too low-level for being dealt in the recording actions editor effectively, so this should be thought over.<br>
<br>The second problem should be dealt in the factories. That is they 
shouldn't allow opening "Resize Image" dialog until all the actions in 
the scheduler are finished. The factories for most of the actions can 
use KisProcessingApplicator internally. <br>

<br><br>[1] - <a href="http://community.kde.org/Krita/Recording_System">http://community.kde.org/Krita/Recording_System</a><br>[2] - See QEXPECT_FAIL comment in the unittest:  KisSelectionManagerTest::testResizeToSelection()<br>
</div></div><br clear="all"><br>-- <br>Dmitry Kazakov<br>