recording

[Boudewijn Rempt]

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