recording

[Dmitry Kazakov]

On Mon, May 7, 2012 at 6:19 AM, Sven Langkamp <sven.langkamp at gmail.com>wrote:

>
> Explanation:
>
> Command: A command is contains basically two things: 1) an id string to
> identify the command 2) a KisPropertiesConfiguration that contains the
> parameters
>
> 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.
>
> 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.
>
> Command runner: The class or plugin that executes the command.
>

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]

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.

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.

Although there are two complications.

The first one is related to the fact that we need to save the contents of
QUndoCommand somehow.

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


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.

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.


[1] - http://community.kde.org/Krita/Recording_System
[2] - See QEXPECT_FAIL comment in the unittest:
KisSelectionManagerTest::testResizeToSelection()


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