<br><br><div class="gmail_quote">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 class="im"><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><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>
<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 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>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><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><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">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 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><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><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>
... <br></div></div></blockquote><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><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.<br>
<br>-- <br>Dmitry Kazakov<br>