[Kst] Scripting

[Nicolas Brisset]

> I have been put in charge of adding python scripting to Kst. I am
> interested in hearing what you would like to see in scripting so I can
> be sure to include it.
Bringing back scripting to kst sounds like a great idea. I'll make comments on 3 aspects: the implementation, the API level and the feature set.

1) implementation: I'm not really familiar with how it works in the background, but I think you could ask George Staikos if you or Barth still have contact with him, because he spent a lot of time implementing it in kst 1.x and in general he has very good ideas and lots of experience. Then there's a very important point which is the choice of the language. I believe it is fairly easy to make Qt applications scriptable with QtScript, which is JavaScript. Peter Kümmel also has experience with that and may be helpful there. Otherwise python is very common (see also this http://blogs.kde.org/node/4469) but I don't know exactly what is involved to generate bindings. You may want to look at kross (KDE's language-neutral scripting framework, seems to be stagnating though) and you probably have to contact script-binding gurus on the kde-bindings list. If it is possible to provide bindings to more languages at low cost then it's even better. If we have to choose only one, then I'd say QtScript (for ease of implementation) or python (most widespread).
And probably most important of all: make it in a way that's esay to expand and maintain!

2) API level: with kst1 I never really used built-in scripting, but I used a fair amount of dcop-based shell scripts. I believe the script language provided more or less complete access to relevant kst classes, while dcop provided a more functional approach. We have to discuss that, but dcop (now dbus) is certainly also nice, as it allows people to do simple things from their shell script of choice. I'm not sure providing class-level bindings is as easy for your average Joe user.
My thoughts on this a not very clear, but I think it is worth discussing.

3) feature-set: I'll try to detail it later when I have talked to some colleagues, but I'd say the following actions are a minimal list of required things:
- start/pause/unpause/print/export/load/save/quit
- create/delete plots, add/move/remove curves from plots
- create/delete all objects you can create from the Create menu 
- change sample ranges
- change data file
- tab raise/create/delete/move
- allow extending the app with scripts (like amarok), and launching scripts at startup

I don't know how much time you have, nor how difficult this is going to be. Don't hesitate to keep us posted about your thoughts on the topic, so that we can reach a common understanding and in the end make it really useful.

Nicolas