Re: Extension Proposal (First Draft)
Hi Bryce,
just need a small precision (paragraph 8.1)
You mention plugins as loaded as dynamic objects (so/dll) ans thus being c/c++ (or somewhat compiled).
I was wondering about let's say, something written in Python (because I appreciate this language, and because it is availabe on nearly all platforms). Python (or perl, ruby...) programs can nearly behave as dynamic objects. Would it be considered as a script or a plugin ?
Main only concern is will it be possible writting plugins in interpreted languages (small memory print, easier to develop/maintain, often more portable...)
Regards,
Matiphas
On Mon, 19 Jul 2004, Gazal, Geraud (MED) wrote:
Hi Bryce, I was wondering about let's say, something written in Python (because I appreciate this language, and because it is availabe on nearly all platforms). Python (or perl, ruby...) programs can nearly behave as dynamic objects. Would it be considered as a script or a plugin ?
See the section on Language Bindings. Python scripting (or Perl, Guile, etc.) would be handled by creating a special kind of Plug-in that wrappers the script language interpreter. Inkscape can then pass scripts to that plug-in, which handles mapping the language's function calls to internal calls to Inkscape.
Main only concern is will it be possible writting plugins in interpreted languages (small memory print, easier to develop/maintain, often more portable...)
What we want to avoid is embedding interpreters directly into Inkscape - in order to handle all the various programming languages people would care about would cause simply too much bloat, but choosing one scripting language and excluding all others would not be fair, and would lead to a lot of argument over *which* language to use. But by putting the script interpreters into plug-ins that Inkscape can load up just when needed, we should hopefully get the best of both worlds and sidestep the issues.
Bryce
participants (2)
-
Bryce Harrington
-
Gazal, Geraud (MED)