recording

[Sven Langkamp]

On Wed, May 9, 2012 at 10:12 AM, Boudewijn Rempt <boud at valdyas.org> wrote:

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

Right, but at that point we are about to lose that. My point is that the
values are not stored in the undo command.


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

I had not thought about it, but it looks pretty much identical to it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kimageshop/attachments/20120509/dcc9404f/attachment-0001.html>