qsa, kjsembed, python

[Boudewijn Rempt]

I've checked the scripting situation a bit.

Kexi uses qsa -- or at least, used to do so -- and Zack Rusin has talked about 
a kjsembed with an editor for August this year. And long, long ago, when I 
was still a lot into Python, the Python people were really hyped because 
KOffice was going to be suite-wide scriptable in Python. Dcop, which Krita 
supports, is not an alternative for real application extensibility.

So, faced with selecting a scripting environment for Krita, and while  
personally really wanting Python, I feel that QSA has a strong advantage, 
namely a built-in editor and gui editor, which I don't feel like waiting for 
to appear for Python or kjsembed.

On the other hand, I don't want Krita to break a KOffice standard, it's bad 
enough having different GUI's for Karbon, Krita and Kivio (toolboxes, 
dockers), and different canvases, color implementations and lots more.

Anyway, it's decision time, and since the only other KOffice application that 
supports scripting uses QSA, I think we should go for QSA. I anyone wants to 
integrate QSA into Krita feel free.

My off-the-cuff approach would be:

* Initially expose three objects, KisPaintDevice, KisPainter and KisDoc behind 
three facade objects that limit access a bit. Maybe KisFilter, but that's too 
new for me to know much about.

* Put all scripting stuff in a separate directory off the main dir, please.

* Put all user scripts in ~/.kde/share/apps/krita/scripts

* Put some global example scripts in /opt/kde3/share/apps/krita/scripts

* Make QSA scripting optional, i.e, there's compile-time check for Kexi, I 
guess, and let's use that.

-- 
Boudewijn Rempt | http://www.valdyas.org/fading/index.cgi