recording

[Boudewijn Rempt]

On Saturday 12 May 2012 May, Dmitry Kazakov wrote:

> What I want to say is that while designing this system I thought about the
> recording as well. But there was one flaw: I was thinking about usual tool
> strokes and processings mostly, and I didn't think about our command-based
> actions that much. That is why the interface of the commands didn't change
> much since the introduction of the strokes. As a result, the strokes fit
> perfectly for recording of the tool strokes and processings, but there are
> still several flaws with recording of commands and emitting commands'
> dialogs (about both you wrote about).

I'm sort of sure I remember we discussed this before the strokes work was started, though -- I've always wanted to integrate all of that in one system. And in fact, things like scaling are now ported to strokes already, aren't they?

> The only thing that is higher than the strokes framework is configuration
> Dialog for an action. All the rest is exactly what the framework was
> designed for. Yes, currently, the commands are handled separately and you
> would have to introduce toXML/fromXML methods for each command to record
> them. I totally agree that this is not the best way to record it. But we
> can easily change it to any way we need. This is a matter of adding one
> strategy class to the strokes system. We just need to agree what we need
> and design it.

I think we should use the properties class here -- we can pass that along, only needing to serialize/deserialize to xml when writing to disk or reading a recorded action from disk.

But I really want to figure out a way to describe these actions, then generate the code, or make it completely dynamic. Writing one class per action is what the current recording framework wants, and it's just too much work.
 
> > 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.
> >

<...>

> 
> 1) The caller asks KisStrokeStrategyFactoryRegistry for the factory of
> "ScaleLayer" stroke.
> 2) The factory does the following: i) calls image->barrierLock() to fetch
> right size information about the image; ii) calls image->unlock(); iii)
> fires up the configuration dialog.
> 3) The factory creates the stroke strategy for the "ScaleLayer" stroke
> (usual undo command based stroke)
> 4) The factory uploads the XML data about the stroke into the strategy
> 4) The factory starts a new stroke and populates it with commands
> 5) The strokes system calls the stroke strategy's method toXML, which saves
> the data

Hm, compared to Sven's suggestion, this sounds pretty complicated -- but isn't it actually the same?

Where Sven says "command is send to the command switch that looks up the id" -- that's the part where the registry is asked to find the actual implementation. I just wouldn't pass round the xml, but the properties object. We're already way too cavalier about string manipulation in Krita.

I'm also not sure where this system hits the undo system, actually -- it sort of seems only tangentially related, especially because undo stores the pixel data, not the command parameters.


-- 
Boudewijn Rempt
http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl