<div class="gmail_quote">On Tue, May 15, 2012 at 6:57 PM, Dmitry Kazakov <span dir="ltr"><<a href="mailto:dimula73@gmail.com" target="_blank">dimula73@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><br><div class="gmail_quote"><div class="im">On Tue, May 15, 2012 at 7:39 PM, Sven Langkamp <span dir="ltr"><<a href="mailto:sven.langkamp@gmail.com" target="_blank">sven.langkamp@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div>1) In several cases we must to barrierLock the image before showing the dialog, in others we needn't. It means we need to have a general code for this locking in the base class.<br>
2) The second reason is even more important. The user should be able to see the dialog for the recorded actions. He can use it either for editing the recorded action or for modifying the action on-the-go. Both the usecases are implemented in PS.<br>
</div></div></blockquote><br></div><div>This is only needed for showing the widget. I think we can handle the UI and the data extraction seperately. First we switch the data to KisPropertiesConfiguration with the UI still working as it's now. Once that is done, we can handle the rest.<br>
</div></div></blockquote></div><div><br>It will demand at least two classes for a single action, won't it?<br><br>Or you suggest the generation of the dialog purely on the basis of properties data? If so, how are you going to create and use customized widgets like the one in Resize Canvas and in Filters dialog?<br>
</div></div></blockquote><div><br>No, it's like we do with filters currently. There we also dialog that writes into a properties configuration. We already have the dialogs, they would just need some tweaking so they could also be used in the macro editor.<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="gmail_quote"><div></div><div class="im"><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="gmail_quote"><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="gmail_quote"><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="gmail_quote"><div>The XML data you mention could be much easier be done with the KisPropertiesConfiguration. There is no way around it as we have to save the input values at some point. This should also be used by scripts and macros I think.<br>
</div></div></blockquote></div><div><br>Yes, I agree. The highlevel code in factories can surely use it. What I'm not sure about is whether properties can work good for usual strokes, which might contain very long array of short values (points). Is it possible to do without working it around with a set of preperties pt1,pt2,...,ptN?<br>
</div></div></blockquote></div><div><br>It's enough for the filter and I don't think the other actions are more complicated. Arrays can be saved like curves, were the list is serialize before it's stored in the properties. If we are missing properties we can also add them to KisPropertiesConfiguration.<br>
</div></div></blockquote></div><div><br>Well, we need to add array methods to the properties then. Anyway, I think we should use on the high level only, before passing to the strokes.<br></div></div></blockquote><div><br>
Should be easy to do. I wonder where we use arrays in the UI (appart from curves),<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="gmail_quote">
<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="gmail_quote"><div class="im"><div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">One class for each action sounds very heavy. We have probably over a hundred action that are possible and I think we should keep the needed code to a minimum. Maybe we need to pick some simple action and then think it through and check which changes would be needed. We really need to get it right before the big porting starts.<br>
</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="gmail_quote"><div><br>Yes, sure. We can start with, e.g. "ScaleImage" method of KisImage. It is already ported to the strokes, so it is easier to port it =)<span><font color="#888888"><br>
</font></span></div>
</div></blockquote></div></div><div><div class="im"><br>Ok. So in the image size dialog we currently have:<br><br> if (dlgImageSize->exec() == QDialog::Accepted) {<br> qint32 w = dlgImageSize->width();<br>
qint32 h = dlgImageSize->height();<br></div>
... <br></div></div></blockquote><div class="im"><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_quote"><div> ...processCommand(KisActionCommand* command) {<br>
qint32 width = command->getInt("width");<br> ...<br>
scaleImage(width, ...);<br>
}<br><br>This code could be auto-generated, if we generate the methods that do the set/get of the properties.<br></div></div></blockquote></div></div><br>I'm sorry, I haven't understood what you meant with this code. It neither solves the problems I told about (serialization of the dialogs, encapsulation of the dialogs for editing) nor allows us to avoid additional string juggling, about which Boud was talking about.<span class="HOEnZb"><font color="#888888"></font></span><br>
</blockquote></div><font color="#888888"><br></font>Serialization and encapsulation of the dialogs are totally different problems, this is just how we get the data from the widget to the function inside Krita. I think the string juggeling Boud was talking about is when you save to XML and then flatten the XML document to a string.<br>