Re: Re: GePhex and scripting
Georg Seidel <[email protected]>
| Newsgroups | gmane.comp.video.gephex.devel |
|---|---|
| Message-ID | <[email protected]> |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I just read through some articles and postings about extending applications with scripting languages (thanks to teemu for the links). In http://twistedmatrix.com/users/glyph/rant/extendit.html, the author strongly argues for extending an existing language (python in this example), by loading your application as a library, and doing all the high level stuff in the scripting language. He has some good points, but I can't follow his conclusion. For example, he does not mention issues like debugging etc. He also argues not to use application specific plugin mechanisms, but instead to use only the library loading mechanism of the respective scripting language. I think that in our case (real-time image manipulation), our separate plugin mechanism is rectified. Also, I somehow don't like such an intimate tangling of the application with the specifics of the scripting language... The author also links to this article http://advogato.org/article/550.html, which compares the scripting interface of vi, emacs and gimp, and comes to the conclusion that it's best to support multiple scripting languages, all on the same level. The last comment is from the author of the first article, and argues against supporting many scripting languages, but rather to support one really well. I think it's time to decide what kind of extension language we want to support in gephex-0.5, and how. Let me summarize my current understanding of our design: ~ 1/ implement the core as a library, without any asynchronous operation ~ (update loop) ~ 2/ somehow integrate a scripting language to use ~ this core and export *all* core functionality to that language ~ 3/ current language candidate: scheme (guile) ~ 4/ use that scripting language as an interface to the gui ~ (i.e. gui can be written in any language, but uses the scripting ~ language to communicate with the core) Here are some thoughts: ~ * it would be really great if we could use that same extension ~ language from within the gui to automate stuff (for example I think ~ of writing a small script that toggles different effects or changes ~ parameter values of effects) ~ * as martin mentioned, it would be cool to be able to implement new ~ effects and link types in a scripting language. ~ but unlike his proposal to build a special plugin that imports ~ the "script effects", I propose to incorporate this functionality ~ directly into our scripting language: ~ To implement a new effect, you would have to write the relevant ~ functions (init, update, ..) in scheme (or python or whatever), ~ and then call a function ~ "(register-effect my-init my-update ...)" ~ to register it. ~ This should not be hard to implement, because the concept of a ~ library is well factored out inside the gephex core (see the ~ ILibrary interface). ~ Related to this: does anybody know the details of the script-fu ~ stuff in the gimp? I think it is a scheme dialect. It would be ~ *really* cool to be able to use some image filters from gimp in ~ gephex... ~ * what about python, or even another language? ~ I favor scheme, but it's largely a matter of my personal taste, ~ I think. ~ I can see the following advantage of python: it has a richer, ~ more mature (and standardized) set of functions to deal with stuff ~ like files, threads, regexps, ... ~ scheme lacks most of this, and every scheme dialect adds it's own ~ set of functions. ~ A second advantage of python is a larger user base. ~ The advantages of scheme I see is the extremely easy syntax ~ and it's success in wide-spread applications ~ (emacs (okay, it's a lisp dialect...), gimp, autocad). I'm waiting for your comments! georg -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFAsJSJ/rP0cdKF/ToRAkyKAKC+aTKllEH+zKLQDHxINWwgcGYj/wCgpHOH XWrDs783cg0UeATXmtYpXdE= =Uecd -----END PGP SIGNATURE-----