Sven Langkamp sven.langkamp at
Tue May 15 18:11:50 UTC 2012

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

> On Tue, May 15, 2012 at 7:39 PM, Sven Langkamp <sven.langkamp at>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

> 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

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

More information about the kimageshop mailing list