qsa, kjsembed, python
boud at valdyas.org
Wed Jul 28 14:27:29 CEST 2004
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
More information about the kimageshop