Yes, we surely need some automation here. The three systems work quite independently now, we need to connect or merge them a bit. I'll try to write what I know about them. <br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


** The recording design document (<a href="http://community.kde.org/Krita/Recording_System" target="_blank">http://community.kde.org/Krita/Recording<span title="Закрыть" id="flyBannerClose"></span>_System</a>) only talks about tool actions, but menu actions and shortcuts should also be recorded.<br>
</blockquote><div><br>Well, there is a good thing in these actions: all of them (with only few exceptions) go through the undo system. That is the point where we can catch all of them and cover with the recording. At least that is what I thought about when writing that document.<br>
<br>So, now all the actions performed in Krita belong to one of the four types:<br><br>1) Synchronous (old) way. Execution of these actions will block both updates and the strokes framework.<br><br>1.1) Single command actions<br>
The caller creates one KUndo2Command and pushes it into the undo stack. The name of the action is stored in the text() field of the command, the actions are performed in the redo() method.<br><br>1.2) Multiple command actions.<br>
The caller starts a macro using the undo adapter. The adapter blocks the strokes and updates. Then all the commands are executed sequentially. The name of the action is stored in the text() of the macro.<br><br>2) Asynchronous (strokes') way of running actions. At first, the caller puts such an action into the queue. Then the scheduler executes it sequentially or in parallel using its own threads. We have two kinds of such actions:<br>
<br>2.1) Tool-strokes <br><br>Examples are: FreehandStrokeStrategy, MoveStrokeStrategy.<br><br>These actions do not use any commands for execution of an action. They do the modifications directly by means of the callbacks, which are called by the scheduler itself. In the end of such an action, the caller (the stroke strategy) adds a KUndo2Command to the KisPostExecutionUndoAdapter. This adapter differs from the regular one in two aspects: first, it doesn't call redo() method of the undo command on it's addition to the stack, and second, it ensures that when the user requests undo or redo these commands are executed in exactly the same way as they were executed in the stroke. This includes threads and sequentiality properties.<br>
<br>2.2) KisProcessingApplicator-based actions.<br><br>These actions are simple KUndo2Command-based actions with the only difference, they run in the scheduler, so that they can be multithreaded. Internally, the applicator starts a stroke (KisStrokeStrategyUndoCommandBased), so there is no difference for the scheduler which type of the action is running now. And this stroke uses KisPostExecutionUndoAdapter as well.<br>
<br><br>As far as I can see, we can do the recording quite easily by using the KisStrokesFacade interface of the KisImage. What we need is to add toXML/fromXML methods to the strokes' classes (which was planned, but not yet implemented).<br>
<br>What exactly is needed:<br><br>1) Add toXML/fromXML to KisStrokeStrategy classes and create a Factory for them.<br>2) Add toXML/fromXML to KisStrokeJobData classes  and create a Factory for them.<br>3) Add toXML/fromXML to KUndo2Command classes  and create a Factory for them.<br>
4) Add toXML/fromXML to KisProcessingVisitor classes  and create a Factory for them.<br><br>Then we just need to create a class which derives KisStrokesFacade and records everything what is done with strokes. Then just link it to KisImage. <br>
<br>If we do this, there will be one problem: the actions which are executed using the legacy adapter are managed by the strokes facade. There are two solutions possible: we can modify the adapter to record KUndoCommands (which is not so difficult, considering we added toXML/fromXML to them) or we can finish porting all the actions to the strokes.<br>
<br><br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

* Strokes:<br>
<br>
Strokes also transfer information about the action to be done on to an entity that executes the actual thing to be done. For painting, for instance, both FreehandStroke and KisRecordedPaintAction store the state of the canvas resources. Duplication? Can we share stuff?</blockquote>
<div><br>Yes, right now KisResourcesSnapshot has a method setupPaintAction(), which transfers the resources information into the paint action. We can just add toXML/fromXML methods to the KisResourcesSnapshot directly and call them from the corresponding methods of the stroke strategy. Then we will have no need of paint actions anymore.<br>
 </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> Actually porting Krita to the strokes framework isn't finished yet either. <a href="http://community.kde.org/Krita/Recording_System" target="_blank">http://community.kde.org/<u></u>Krita/Recording_System</a> talkes about integrating recording and strokes -- is that done already?<br>
</blockquote><div><br>Well, what is done and what is not done:<br><br>1) The strokes framework itself is done. It is quite stable, and there is only one small problem I can think about [0].<br>2) Recording for the strokes is not done. I haven't even started it. But the whole system was designed with the thought that it can be added later.<br>
3) Not all the actions are ported to strokes.<br><br>[0] - the problem is connected with the creation of the undo commands. They are created outside strokes which means they can have wrong information about the image. Currently, this can be reproduced in the tests only (see KisSelectionManagerTest::testResizeToSelection).<br>
<br> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

* Scripting:<br>

What about it? And remote instrumenting using dbus? We have a barely compiling, hardly useful scripting plugin that uses kross, and users can create generators and filters with shiva, which solves at least one part of the scripting needs. But I'm not sure we shouldn't figure out a way to integrate scripting and recording.<br>
</blockquote><div><br>I don't know about it much.<br> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

* Generation:<br>

Couldn't we come up with something that would generate strokes, recorder and actions from one or more xml files?<br></blockquote><div><br>I'm not sure what you meant by this. I guess the idea with saving strokes to the XML can solve this problem.<br>
 <br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
** Actions<br>
<br>
Every action should be recordable. Actions lead to dialogs, </blockquote><div><br>Here is a problem that may appear. Actions may read some information about the image, which may be changing at the time. So the dialogs should either lock() the image or be opened in some undo commands (which is not cool).<br>
<br> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">act directly or activate tools.<br>
Should tool activation be recordable?<br></blockquote><div><br>I don't think that tool activation and activation of the nodes should be recordable, because it is saved in the resources, but the visibility of the layers should recorded.<br>
</div></div><br clear="all"><br>-- <br>Dmitry Kazakov<br>