recording

[Sven Langkamp]

On Tue, May 15, 2012 at 6:57 PM, Dmitry Kazakov <dimula73 at gmail.com> wrote:

>
>
> On Tue, May 15, 2012 at 7:39 PM, Sven Langkamp <sven.langkamp at gmail.com>wrote:
>
>> 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.
>>> 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.
>>>
>>
>> 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.
>>
>
> It will demand at least two classes for a single action, won't it?
>
> 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?
>

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.


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

Should be easy to do. I wonder where we use arrays in the UI (appart from
curves),


> 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.
>>>
>>
>>> 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 =)
>>>
>>
>> Ok. So in the image size dialog we currently have:
>>
>>     if (dlgImageSize->exec() == QDialog::Accepted) {
>>         qint32 w = dlgImageSize->width();
>>         qint32 h = dlgImageSize->height();
>> ...
>>
>     ...processCommand(KisActionCommand* command) {
>>         qint32 width = command->getInt("width");
>>         ...
>>         scaleImage(width, ...);
>>     }
>>
>> This code could be auto-generated, if we generate the methods that do the
>> set/get of the properties.
>>
>
> 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.
>

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kimageshop/attachments/20120515/69bfbec6/attachment-0001.html>