[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-kimageshop
Subject:    Re: recording
From:       Boudewijn Rempt <boud () valdyas ! org>
Date:       2012-05-15 7:24:27
Message-ID: 201205150924.27879.boud () valdyas ! org
[Download RAW message or body]

On Tuesday 15 May 2012 May, Sven Langkamp wrote:

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

I agree here -- if we just pass properties objects around until the time comes to \
serialize to disk we save a lot of string work. And the properties class knows how to \
serialize/deserialize already.

> 
> I'm not sold on the undo command based stroke. These tend to really make
> the code more complicated and I would prefer if we could make this more
> simple. Might be better to base it on KisStrokeJob. Btw we really need more
> documentation for the Strokes system, without it's pretty hard to grasp
> what the classes do or what sequentiality and exclusivity do.

There is a pretty good paper on the strokes framework in krita/doc/strokes, but I \
agree that the apidox are lacking a lot -- but that's true all over Krita. I've been \
hacking a lot recently, and I'm continuously running into this problem. For example, \
the path from the setting the buildup/wash mode to the actual implementation is not \
just tortuous, it's also undocumented.

The paintop option system is much refined these days, compared to when I wrote it \
first, but it's also almost completely undocumented...

> 
> 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 -- and there must be a way (other than rewriting all of krita's gui in Python or \
Javascript) to make this more dynamic or at least generated.

-- 
Boudewijn Rempt
http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl
_______________________________________________
kimageshop mailing list
kimageshop@kde.org
https://mail.kde.org/mailman/listinfo/kimageshop


[prev in list] [next in list] [prev in thread] [next in thread]