recording

[Dmitry Kazakov]

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.

** The recording design document (http://community.kde.org/Krita/Recording
> _System) only talks about tool actions, but menu actions and shortcuts
> should also be recorded.
>

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.

So, now all the actions performed in Krita belong to one of the four types:

1) Synchronous (old) way. Execution of these actions will block both
updates and the strokes framework.

1.1) Single command actions
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.

1.2) Multiple command actions.
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.

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:

2.1) Tool-strokes

Examples are: FreehandStrokeStrategy, MoveStrokeStrategy.

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.

2.2) KisProcessingApplicator-based actions.

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.


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

What exactly is needed:

1) Add toXML/fromXML to KisStrokeStrategy classes and create a Factory for
them.
2) Add toXML/fromXML to KisStrokeJobData classes and create a Factory for
them.
3) Add toXML/fromXML to KUndo2Command classes and create a Factory for them.
4) Add toXML/fromXML to KisProcessingVisitor classes and create a Factory
for them.

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.

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.


* Strokes:
>
> 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?


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.


> Actually porting Krita to the strokes framework isn't finished yet either.
> http://community.kde.org/**Krita/Recording_System<http://community.kde.org/Krita/Recording_System>talkes about integrating recording and strokes -- is that done already?
>

Well, what is done and what is not done:

1) The strokes framework itself is done. It is quite stable, and there is
only one small problem I can think about [0].
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.
3) Not all the actions are ported to strokes.

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



> * Scripting:
> 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.
>

I don't know about it much.


> * Generation:
> Couldn't we come up with something that would generate strokes, recorder
> and actions from one or more xml files?
>

I'm not sure what you meant by this. I guess the idea with saving strokes
to the XML can solve this problem.


> ** Actions
>
> Every action should be recordable. Actions lead to dialogs,


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



> act directly or activate tools.
> Should tool activation be recordable?
>

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.


-- 
Dmitry Kazakov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kimageshop/attachments/20120317/7e99341c/attachment.html>