recording

[Sven Langkamp]

On Tue, May 8, 2012 at 3:10 PM, Dmitry Kazakov <dimula73 at gmail.com> wrote:

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

The commands at I was talking about are not QUndoCommands. It's also not on
the same level as the strokes framework.

QUndoCommand is too low-level. Action might map undo commands that are
missing information that is needed for recording e.g. the selection tools
use a normal transaction. Beside that I don't want to add xml loading and
saving code to every undo command.

Runners are on a much higher level than the strokes framework. For example
a possible runner could be the current KisLayerManager.

For example if you want to scale a layer:
1) Dialog saves the values into a KisPropertiesConfiguration of a command,
id is set to e.g. "scaleLayer"
2) Command is then send to the "command switch", that looks at the and
looks up the runner for id "scaleLayer"
3) Command is then send to the KisLayerManager, which reads command id
"scaleLayer" from which is knows the function to call and the values to read
4) KisLayerManager reads the values and calls KisLayerManager::scaleLayer

Recording happens in step 2, when the command goes through the "command
switch". Recording can't happen in step 4 as we have just transactions at
that point and no information about the original dialog values anymore.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kimageshop/attachments/20120508/0f8faecf/attachment.html>