<br><br><div class="gmail_quote">On Tue, May 15, 2012 at 11:34 AM, Boudewijn Rempt <span dir="ltr"><<a href="mailto:boud@valdyas.org" target="_blank">boud@valdyas.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Saturday 12 May 2012 May, Dmitry Kazakov wrote:<br></div></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="im">
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?<br>
</div></blockquote><div><br>Yes, some of the time-consuming methods of KisImage like rotation and scaling are already ported to strokes.<br><br><br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

<div class="im">
> The only thing that is higher than the strokes framework is configuration<br>
> Dialog for an action. All the rest is exactly what the framework was<br>
> designed for. Yes, currently, the commands are handled separately and you<br>
> would have to introduce toXML/fromXML methods for each command to record<br>
> them. I totally agree that this is not the best way to record it. But we<br>
> can easily change it to any way we need. This is a matter of adding one<br>
> strategy class to the strokes system. We just need to agree what we need<br>
> and design it.<br>
<br>
</div>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.<br></blockquote><div><br>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?<br>
<br> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

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.<br>
</blockquote><div class="im"><br>Well, I'm afraid we would need to reimplement GEGL and do the graph thing for that ;)<br> <br>
<br>
</div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hm, compared to Sven's suggestion, this sounds pretty complicated -- but isn't it actually the same?<br>
</blockquote><div><br>Yes, it is almost the same, but is adapted to what we have now.<br> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

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</blockquote><div><br>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.<br>
<br>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.<br>
</div><div> <br> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

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.<br></blockquote><div><br>It connects with the undo system in the only point: the corresponding recorded action should be canceled, when something has been undone.<br>
<br clear="all"></div></div><br>-- <br>Dmitry Kazakov<br>