recording

[Boudewijn Rempt]

On Tuesday 08 May 2012 May, Sven Langkamp wrote:

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

But at 4 we should have access the to relevant values that make up this command, shouldn't we?

I'm wondering if what we're trying to reinvent isn't similar to gimp's PDB -- or maybe I'm mistaken about the purpose of that concept.


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