recording

[Dmitry Kazakov]

On Tue, May 15, 2012 at 11:34 AM, Boudewijn Rempt <boud at valdyas.org> wrote:

> On Saturday 12 May 2012 May, Dmitry Kazakov wrote:
>


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

Yes, some of the time-consuming methods of KisImage like rotation and
scaling are already ported to strokes.


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

The only concern I have about properties is whether they can store large
arrays of small objects efficiently. Anyway, I don't think there is a
reason for keeping all the processed data (including the Map and all the
strings) after the formation of data has been completed and the stroke has
been finished. Is there any?



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

Well, I'm afraid we would need to reimplement GEGL and do the graph thing
for that ;)


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

Yes, it is almost the same, but is adapted to what we have now.


> 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


The registry does not store the XML, it stores factories. The factory might
have two constructors: fromXML and direct one. So there should be no
juggling with strings in this case.

We might probably need to rename "factory" into something else, because it
is more than just a factory. It is something like a "command" with the
ability to be constructed from XML. The problem is that "command" and
"action" terms are already reserved.



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

It connects with the undo system in the only point: the corresponding
recorded action should be canceled, when something has been undone.


-- 
Dmitry Kazakov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kimageshop/attachments/20120515/fd88de74/attachment.html>