[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-kimageshop
Subject:    Re: recording
From:       Boudewijn Rempt <boud () valdyas ! org>
Date:       2012-05-15 7:34:52
Message-ID: 201205150934.52137.boud () valdyas ! org
[Download RAW message or body]

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
_______________________________________________
kimageshop mailing list
kimageshop@kde.org
https://mail.kde.org/mailman/listinfo/kimageshop


[prev in list] [next in list] [prev in thread] [next in thread]