On March 23, 2013 at 6:16 PM Krzysztof Kosiński <tweenk.pl@...400...> wrote:
2013/3/23 Bric <bric@...2538...>:
First, on behalf of all who use Perl: "Aaaaah!" :-)
There is a conflict of interest between people who want to use their favorite language X, and the developers of Inkscape who would like to keep the number of distinct languages used in the codebase to a minimum.
Note that you can still use Perl-based extensions, this component was about something else.
Second, do you mean, it actually DID work on SOME platforms? Which ones? (if this is documented, please point me to the docs)
As far as I know, there was no documentation at all.
I suppose, the decision to throw a functionality overboard, only because it can't be provided on ALL platforms, would be an arbitrary decision? A decision made by Inkscape alone, and not dictated by outside policies or some such?
There wasn't much "functionality" in the first place.
There are two models of scripting in Inkscape. The first model is to pass the entire document to the script, along with information on which IDs are selected. This works reasonably well and you can still
Hi, Krzysztof:
So, I should focus on the first model. What I don't understand here is "to pass": What is doing the "passing"? From where to where? Do you mean simply parsing the svg file, using Perl/Python/whatever, completely outside and apart from Inkscape? Or is there some sort of integration with Inkscape -- as in, the script extends the Inkscape interface somehow?
use Perl for this. The second model is to allow scripts to manipulate Inkscape's SVG DOM. This second model never really worked; there was a GSoC project to provide a DBus-based binding to the DOM, and it partially works (although it has serious deficiencies), but with the recent plans of moving DBus into the kernel, it looks like this is not a cross-platform solution. AFAIK the removed Perl component was an attempt to support using Perl with the second model.