I can't find any documentation on the Perl component.
When I compiled 0.48.4 I used --with-perl, which looked promising.
How do I use this component?
thanks
If I recall correctly, it wasn't actually really used as it had cross platform issues. If I'm not mistaken it was even removed from trunk recently.
Cheers, Josh On Mar 22, 2013 7:14 PM, "Bric" <bric@...2538...> wrote:
I can't find any documentation on the Perl component.
When I compiled 0.48.4 I used --with-perl, which looked promising.
How do I use this component?
thanks
Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On March 22, 2013 at 11:20 PM Josh Andler <scislac@...400...> wrote:
If I recall correctly, it wasn't actually really used as it had cross platform issues. If I'm not mistaken it was even removed from trunk recently.
First, on behalf of all who use Perl: "Aaaaah!" :-)
Second, do you mean, it actually DID work on SOME platforms? Which ones? (if this is documented, please point me to the docs)
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?
But there are many applications that work exclusively on one platform or another, and there are many open-source applications, actually, that work fully on platform X but only partially on platform Y... (at certain (passing) phases of development)
There is no obligation (to some steak-holders), to keep it all symmetric, is there?
Cheers, Josh
On Mar 22, 2013 7:14 PM, "Bric" <bric@...2538... mailto:bric@...2538... > wrote:
I can't find any documentation on the Perl component.
When I compiled 0.48.4 I used --with-perl, which looked promising.
How do I use this component?
thanks
Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net mailto:Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
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 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.
Regards, Krzysztof
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.
fwiw, there is a working Perl extension called txt2svg.pl in the share\extensions directory, along with the corresponding .inx file. It can be used to import text files. As far as I know these extensions all work by creating a temporary file and saving the entire svg document to the file and then reloading it after the extension is complete.
Alvin
-- View this message in context: http://inkscape.13.n6.nabble.com/documentation-on-the-Perl-component-tp49663... Sent from the Inkscape - Dev mailing list archive at Nabble.com.
On Mar 25, 2013, at 6:14 PM, Bric wrote:
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?
The general approach for extensions is to invoke the script and then pass it the SVG xml through stdin. Then it processes the data and returns the new version to stdout. Extra settings, options, selection, etc. are passed in as parameters to the invoked script.
participants (5)
-
alvinpenner
-
Bric
-
Jon Cruz
-
Josh Andler
-
Krzysztof Kosiński