recording

[Dmitry Kazakov]

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?



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


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

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