ScriptingLanguages - Revision history

Romain2Boss: Links

2012-12-26T14:53:31Z

Links

← Older revision		Revision as of 14:53, 26 December 2012
Line 10:		Line 10:
	I think the core scripting interface should be relatively simple and language-neutral, like [[The_Gimp]]'s PDB, though object-oriented. A slightly perverse idea might be to use the Ruby interpreter's excellent C API for this purpose. But that's just one idea.		I think the core scripting interface should be relatively simple and language-neutral, like [[The_Gimp]]'s PDB, though object-oriented. A slightly perverse idea might be to use the Ruby interpreter's excellent C API for this purpose. But that's just one idea.

	Another great scripting language is called [http://www.lua.org Lua]: very small footprint, great flexibility, can be easily embedded into any C[[/C]]++ application without any strings attached (LGPL). [http://www.lua.org Lua] is being largely used for game development. There are cases from Microsoft and Lucas Arts using it.		Another great scripting language is called [http://www.lua.org Lua]: very small footprint, great flexibility, can be easily embedded into any C/C++ application without any strings attached (LGPL). [http://www.lua.org Lua] is being largely used for game development. There are cases from Microsoft and Lucas Arts using it.

	Another idea is to start extending with [http://www.corba.org CORBA], while it is a bit combersome to start out with, we end up not having to support individual languages. I think with a few examples of functionality implemented in those languages it would be easy for many people to pick up closely. The list of supported languages for [http://www.gnome.org/projects/ORBit2/index.html ORBit] is pretty large, and something we could build on.		Another idea is to start extending with [http://www.corba.org CORBA], while it is a bit combersome to start out with, we end up not having to support individual languages. I think with a few examples of functionality implemented in those languages it would be easy for many people to pick up closely. The list of supported languages for [http://www.gnome.org/projects/ORBit2/index.html ORBit] is pretty large, and something we could build on.

Kris: linkfix

2012-03-01T16:35:57Z

linkfix

← Older revision		Revision as of 16:35, 1 March 2012
Line 20:		Line 20:
	Oh, and we need to draw the line at simple reflection stuff (class membership, class name, method names and prototypes), or else we really will end up reimplementing CORBA (badly) all over again...		Oh, and we need to draw the line at simple reflection stuff (class membership, class name, method names and prototypes), or else we really will end up reimplementing CORBA (badly) all over again...

	-- [[MenTaLguY]]		-- [[User:MenTaLguY\|MenTaLguY]]

	----		----
Line 49:		Line 49:
	</pre>		</pre>

	-- [[JonCruz]]		-- [[User:JonCruz\|JonCruz]]

	----		----
Line 63:		Line 63:
	It's written in C, is fast and low weight. I'm waiting to write new effects to Inkscape with my prefered language! :-)		It's written in C, is fast and low weight. I'm waiting to write new effects to Inkscape with my prefered language! :-)

	-- [[AurelioAHeckert]]		-- [[User:AurelioAHeckert\|AurelioAHeckert]]

Colin Marquardt: Clean up wiki markup.

2006-07-03T08:50:48Z

Clean up wiki markup.

← Older revision		Revision as of 08:50, 3 July 2006
Line 1:		Line 1:
	I ~~beliave~~ that EMCAScript (which is basically the same as JS) is a very good addition as it is standardized by W3C and has a ready defined binding to SVG [http://http://www.w3.org/TR/SVG11/ecmascript-binding.html W3C Link to EMCAScript - SVG]. This would be a great shortcut to accessing the SVG structure for non XML geeks ;)		I believe that EMCAScript (which is basically the same as JS) is a very good addition as it is standardized by W3C and has a ready defined binding to SVG [http://http://www.w3.org/TR/SVG11/ecmascript-binding.html W3C Link to EMCAScript - SVG]. This would be a great shortcut to accessing the SVG structure for non XML geeks ;)
	--[[User:Xpressivo\|Xpressivo]] 15:55, 2 July 2006 (PDT)		--[[User:Xpressivo\|Xpressivo]] 15:55, 2 July 2006 (PDT)

			----

	Lilypond is a musical typesetter. All of its internal structure is exported via scheme. I think inkscape should aim for this as it has paid off for lilypond in reduced time in adding functionality and ease of tweaking. My personal preference is python, being a language which sucks in new users at a phenominal rate, and provides the [http://www.boost.org/ Boost] [http://www.boost.org/libs/python/doc/index.html Seamless Python] integration.		Lilypond is a musical typesetter. All of its internal structure is exported via scheme. I think inkscape should aim for this as it has paid off for lilypond in reduced time in adding functionality and ease of tweaking. My personal preference is python, being a language which sucks in new users at a phenominal rate, and provides the [http://www.boost.org/ Boost] [http://www.boost.org/libs/python/doc/index.html Seamless Python] integration.
Line 12:		Line 14:
	Another idea is to start extending with [http://www.corba.org CORBA], while it is a bit combersome to start out with, we end up not having to support individual languages. I think with a few examples of functionality implemented in those languages it would be easy for many people to pick up closely. The list of supported languages for [http://www.gnome.org/projects/ORBit2/index.html ORBit] is pretty large, and something we could build on.		Another idea is to start extending with [http://www.corba.org CORBA], while it is a bit combersome to start out with, we end up not having to support individual languages. I think with a few examples of functionality implemented in those languages it would be easy for many people to pick up closely. The list of supported languages for [http://www.gnome.org/projects/ORBit2/index.html ORBit] is pretty large, and something we could build on.

	---		----

	Corba's C++ binding is nasty, though, which IMO has a great deal to do with why it's not more prevalent. I think, for the sake of bindings to other languages, all we really neede is a very thin wrapper layer that adds the necessary reflection facilities to C++'s in order for a language like Python or Ruby or whatever to generate bindings dynamically at runtime.		Corba's C++ binding is nasty, though, which IMO has a great deal to do with why it's not more prevalent. I think, for the sake of bindings to other languages, all we really neede is a very thin wrapper layer that adds the necessary reflection facilities to C++'s in order for a language like Python or Ruby or whatever to generate bindings dynamically at runtime.
Line 20:		Line 22:
	-- [[MenTaLguY]]		-- [[MenTaLguY]]

	---		----

	I think the key here is coming up with a way to load the modules in, independent of what language they are in - then lanuage bindings can grow and grow - but always be useful. I'll start some more discussion on this in [[ModuleFormat]].		I think the key here is coming up with a way to load the modules in, independent of what language they are in - then lanuage bindings can grow and grow - but always be useful. I'll start some more discussion on this in [[ModuleFormat]].

			----
	---

	Probably the best thing is to work on the concepts to be exposed. Once they are specified, then it's easy to implement the exposure in different languages.		Probably the best thing is to work on the concepts to be exposed. Once they are specified, then it's easy to implement the exposure in different languages.
Line 38:		Line 39:
	Things off the top of my head:		Things off the top of my head:

			<pre>
	-Document		-Document
	\|-XML / parse tree		\|-XML / parse tree
Line 45:		Line 47:

	-Utility calls / factories		-Utility calls / factories
			</pre>


	-- [[JonCruz]]		-- [[JonCruz]]

	---		----

	More ~~then~~ one language to write extensions can help the development.		More than one language to write extensions can help the development.

	The [http://www.mozilla.org/js/spidermonkey/ [[SpiderMonkey]]] is a great javascript engine, used by Mozilla web browser, and implements the [http://www.mozilla.org/js/language/js20/ [[JavaScript]] 2.0] specification.		The [http://www.mozilla.org/js/spidermonkey/ [[SpiderMonkey]]] is a great javascript engine, used by Mozilla web browser, and implements the [http://www.mozilla.org/js/language/js20/ [[JavaScript]] 2.0] specification.
Line 63:		Line 64:

	-- [[AurelioAHeckert]]		-- [[AurelioAHeckert]]

	~~---~~

Xpressivo at 23:01, 2 July 2006

2006-07-02T23:01:58Z

← Older revision		Revision as of 23:01, 2 July 2006
Line 1:		Line 1:
			I beliave that EMCAScript (which is basically the same as JS) is a very good addition as it is standardized by W3C and has a ready defined binding to SVG [http://http://www.w3.org/TR/SVG11/ecmascript-binding.html W3C Link to EMCAScript - SVG]. This would be a great shortcut to accessing the SVG structure for non XML geeks ;)
			--[[User:Xpressivo\|Xpressivo]] 15:55, 2 July 2006 (PDT)

	Lilypond is a musical typesetter. All of its internal structure is exported via scheme. I think inkscape should aim for this as it has paid off for lilypond in reduced time in adding functionality and ease of tweaking. My personal preference is python, being a language which sucks in new users at a phenominal rate, and provides the [http://www.boost.org/ Boost] [http://www.boost.org/libs/python/doc/index.html Seamless Python] integration.		Lilypond is a musical typesetter. All of its internal structure is exported via scheme. I think inkscape should aim for this as it has paid off for lilypond in reduced time in adding functionality and ease of tweaking. My personal preference is python, being a language which sucks in new users at a phenominal rate, and provides the [http://www.boost.org/ Boost] [http://www.boost.org/libs/python/doc/index.html Seamless Python] integration.

Line 62:		Line 65:

	---		---

	I beliave that EMCAScript (which is basically the same as JS) is a very good addition as it is standardized by W3C and has a ready defined binding to SVG [http://http://www.w3.org/TR/SVG11/ecmascript-binding.html W3C Link to EMCAScript - SVG]. I must agree with a previous comment, Python (and Perl) are not really top notch OOP languages. Lets stick with the standards.
	~~--[[User:Xpressivo\|Xpressivo]] 15:55, 2 July 2006 (PDT)~~

Xpressivo at 22:58, 2 July 2006

2006-07-02T22:58:43Z

← Older revision		Revision as of 22:58, 2 July 2006
Line 63:		Line 63:
	---		---

	I beliave that EMCAScript (which is basically the same as JS) is a very good addition as it is standardized by W3C and has a ready defined binding to SVG [http://http://www.w3.org/TR/SVG11/ecmascript-binding.html W3C Link to EMCAScript - SVG]		I beliave that EMCAScript (which is basically the same as JS) is a very good addition as it is standardized by W3C and has a ready defined binding to SVG [http://http://www.w3.org/TR/SVG11/ecmascript-binding.html W3C Link to EMCAScript - SVG]. I must agree with a previous comment, Python (and Perl) are not really top notch OOP languages. Lets stick with the standards.
	--[[User:Xpressivo\|Xpressivo]] 15:55, 2 July 2006 (PDT)		--[[User:Xpressivo\|Xpressivo]] 15:55, 2 July 2006 (PDT)

Xpressivo at 22:55, 2 July 2006

2006-07-02T22:55:24Z

← Older revision		Revision as of 22:55, 2 July 2006
Line 62:		Line 62:

	---		---

			I beliave that EMCAScript (which is basically the same as JS) is a very good addition as it is standardized by W3C and has a ready defined binding to SVG [http://http://www.w3.org/TR/SVG11/ecmascript-binding.html W3C Link to EMCAScript - SVG]
			--[[User:Xpressivo\|Xpressivo]] 15:55, 2 July 2006 (PDT)

Conversion script: link fix

2006-01-22T02:33:47Z

link fix

New page

Lilypond is a musical typesetter. All of its internal structure is exported via scheme. I think inkscape should aim for this as it has paid off for lilypond in reduced time in adding functionality and ease of tweaking. My personal preference is python, being a language which sucks in new users at a phenominal rate, and provides the [http://www.boost.org/ Boost] [http://www.boost.org/libs/python/doc/index.html Seamless Python] integration.

Scripting allows many more developers to contribute, and allows new ideas to be prototyped essentially on the spot.

I think the core scripting interface should be relatively simple and language-neutral, like [[The_Gimp]]'s PDB, though object-oriented. A slightly perverse idea might be to use the Ruby interpreter's excellent C API for this purpose. But that's just one idea.

Another great scripting language is called [http://www.lua.org Lua]: very small footprint, great flexibility, can be easily embedded into any C[[/C]]++ application without any strings attached (LGPL). [http://www.lua.org Lua] is being largely used for game development. There are cases from Microsoft and Lucas Arts using it.

Another idea is to start extending with [http://www.corba.org CORBA], while it is a bit combersome to start out with, we end up not having to support individual languages. I think with a few examples of functionality implemented in those languages it would be easy for many people to pick up closely. The list of supported languages for [http://www.gnome.org/projects/ORBit2/index.html ORBit] is pretty large, and something we could build on.

---

Corba's C++ binding is nasty, though, which IMO has a great deal to do with why it's not more prevalent. I think, for the sake of bindings to other languages, all we really neede is a very thin wrapper layer that adds the necessary reflection facilities to C++'s in order for a language like Python or Ruby or whatever to generate bindings dynamically at runtime.

Oh, and we need to draw the line at simple reflection stuff (class membership, class name, method names and prototypes), or else we really will end up reimplementing CORBA (badly) all over again...

-- [[MenTaLguY]]

---

I think the key here is coming up with a way to load the modules in, independent of what language they are in - then lanuage bindings can grow and grow - but always be useful. I'll start some more discussion on this in [[ModuleFormat]].

---

Probably the best thing is to work on the concepts to be exposed. Once they are specified, then it's easy to implement the exposure in different languages.

Of course, some decisions need to be made as to what to potentially support. This would apply to potential scripting languages and to potential features. Think of both the tasks to accomplish and of the languages to accomplish them in.

For an example of the tasks/concepts, we could think of a raster paint program (like [[The Gimp]] or [[PhotoShop]]). These deal with raster images. Additionally, it's nice to be able to work on images with different numbers of channels, different bit-depths and different colorspaces. The [[PhotoShop]]
plugin API has supported all of this for years. Sadly, [[The Gimp]] did not at the begining. Thus problems with working in CMYK or in bit depths neede for Hollywood work both have been problematic for [[The Gimp]] and its plugins.

Blocking future functionality, I think, is the main thing that Inkscape needs to avoid. As [[MenTaLguY]] has said, it's best if plugins were first-class citizens. So what needs to be exposed?

Things off the top of my head:

-Document
|-XML / parse tree
|-view tree

-UI Thingies / dialogs / user interaction

-Utility calls / factories

-- [[JonCruz]]

---

More then one language to write extensions can help the development.

The [http://www.mozilla.org/js/spidermonkey/ [[SpiderMonkey]]] is a great javascript engine, used by Mozilla web browser, and implements the [http://www.mozilla.org/js/language/js20/ [[JavaScript]] 2.0] specification.

[[JavaScript]] is a easy language and is the defined language to animate SVG. With the powerfull 2.0 version we can do good extensions to Inkscape.

The [[AST]] is a great idea to manipulate the SVG, but may we access in the same DOM used to [[DHTML]]. And it will be natural to DHTML scripters and developers.

It's written in C, is fast and low weight. I'm waiting to write new effects to Inkscape with my prefered language! :-)

-- [[AurelioAHeckert]]

---

AurelioAHeckert: New Proposal

2005-02-14T20:55:35Z

New Proposal

New page

Lilypond is a musical typesetter. All of its internal structure is exported via scheme. I think inkscape should aim for this as it has paid off for lilypond in reduced time in adding functionality and ease of tweaking. My personal preference is python, being a language which sucks in new users at a phenominal rate, and provides the [http://www.boost.org/ Boost] [http://www.boost.org/libs/python/doc/index.html Seamless Python] integration.

Scripting allows many more developers to contribute, and allows new ideas to be prototyped essentially on the spot.

I think the core scripting interface should be relatively simple and language-neutral, like [[The_Gimp]]'s PDB, though object-oriented. A slightly perverse idea might be to use the Ruby interpreter's excellent C API for this purpose. But that's just one idea.

Another great scripting language is called [http://www.lua.org Lua]: very small footprint, great flexibility, can be easily embedded into any C/C++ application without any strings attached (LGPL). [http://www.lua.org Lua] is being largely used for game development. There are cases from Microsoft and Lucas Arts using it.

Another idea is to start extending with [http://www.corba.org CORBA], while it is a bit combersome to start out with, we end up not having to support individual languages. I think with a few examples of functionality implemented in those languages it would be easy for many people to pick up closely. The list of supported languages for [http://www.gnome.org/projects/ORBit2/index.html ORBit] is pretty large, and something we could build on.

---

Corba's C++ binding is nasty, though, which IMO has a great deal to do with why it's not more prevalent. I think, for the sake of bindings to other languages, all we really neede is a very thin wrapper layer that adds the necessary reflection facilities to C++'s in order for a language like Python or Ruby or whatever to generate bindings dynamically at runtime.

Oh, and we need to draw the line at simple reflection stuff (class membership, class name, method names and prototypes), or else we really will end up reimplementing CORBA (badly) all over again...

-- MenTaLguY

---

I think the key here is coming up with a way to load the modules in, independent of what language they are in - then lanuage bindings can grow and grow - but always be useful. I'll start some more discussion on this in ModuleFormat.

---

Probably the best thing is to work on the concepts to be exposed. Once they are specified, then it's easy to implement the exposure in different languages.

Of course, some decisions need to be made as to what to potentially support. This would apply to potential scripting languages and to potential features. Think of both the tasks to accomplish and of the languages to accomplish them in.

For an example of the tasks/concepts, we could think of a raster paint program (like [[The Gimp]] or PhotoShop). These deal with raster images. Additionally, it's nice to be able to work on images with different numbers of channels, different bit-depths and different colorspaces. The PhotoShop
plugin API has supported all of this for years. Sadly, [[The Gimp]] did not at the begining. Thus problems with working in CMYK or in bit depths neede for Hollywood work both have been problematic for [[The Gimp]] and its plugins.

Blocking future functionality, I think, is the main thing that Inkscape needs to avoid. As MenTaLguY has said, it's best if plugins were first-class citizens. So what needs to be exposed?

Things off the top of my head:

-Document
|-XML / parse tree
|-view tree

-UI Thingies / dialogs / user interaction

-Utility calls / factories

-- JonCruz

---

More then one language to write extensions can help the development.

The [http://www.mozilla.org/js/spidermonkey/ SpiderMonkey] is a great javascript engine, used by Mozilla web browser, and inplements the [http://www.mozilla.org/js/language/js20/ JavaScript 2.0] specification.

The JavaScript is a easy language and is the defined language to anime SVG. With the powerful 2.0 version we can do good extensions to Inkscape.

The [[AST]] is a great idea to manipulate the SVG, but may we acess in the same DOM used to [[DHTML]]. And it will be natural to DHTML scripters and developers.

It's writed in C, is fast and low weight. I'm waiting to write new efects to Inkscape with my prefered language! :-)

-- AurelioAHeckert

---

JonCruz: Adding some on design approach and needs

2003-11-08T05:57:40Z

Adding some on design approach and needs

New page

Lilypond is a musical typesetter. All of its internal structure is exported via scheme. I think inkscape should aim for this as it has paid off for lilypond in reduced time in adding functionality and ease of tweaking. My personal preference is python, being a language which sucks in new users at a phenominal rate, and provides the [http://www.boost.org/ Boost] [http://www.boost.org/libs/python/doc/index.html Seamless Python] integration.

Scripting allows many more developers to contribute, and allows new ideas to be prototyped essentially on the spot.

I think the core scripting interface should be relatively simple and language-neutral, like TheGIMP's PDB, though object-oriented. A slightly perverse idea might be to use the Ruby interpreter's excellent C API for this purpose. But that's just one idea.

Another great scripting language is called [http://www.lua.org Lua]: very small footprint, great flexibility, can be easily embedded into any C/C++ application without any strings attached (LGPL). [http://www.lua.org Lua] is being largely used for game development. There are cases from Microsoft and Lucas Arts using it.

Another idea is to start extending with [http://www.corba.org CORBA], while it is a bit combersome to start out with, we end up not having to support individual languages. I think with a few examples of functionality implemented in those languages it would be easy for many people to pick up closely. The list of supported languages for [http://www.gnome.org/projects/ORBit2/index.html ORBit] is pretty large, and something we could build on.

---

Corba's C++ binding is nasty, though, which IMO has a great deal to do with why it's not more prevalent. I think, for the sake of bindings to other languages, all we really neede is a very thin wrapper layer that adds the necessary reflection facilities to C++'s in order for a language like Python or Ruby or whatever to generate bindings dynamically at runtime.

Oh, and we need to draw the line at simple reflection stuff (class membership, class name, method names and prototypes), or else we really will end up reimplementing CORBA (badly) all over again...

-- MenTaLguY

---

I think the key here is coming up with a way to load the modules in, independent of what language they are in - then lanuage bindings can grow and grow - but always be useful. I'll start some more discussion on this in ModuleFormat.

---

Probably the best thing is to work on the concepts to be exposed. Once they are specified, then it's easy to implement the exposure in different languages.

Of course, some decisions need to be made as to what to potentially support. This would apply to potential scripting languages and to potential features. Think of both the tasks to accomplish and of the languages to accomplish them in.

For an example of the tasks/concepts, we could think of a raster paint program (like [[The Gimp]] or PhotoShop). These deal with raster images. Additionally, it's nice to be able to work on images with different numbers of channels, different bit-depths and different colorspaces. The PhotoShop
plugin API has supported all of this for years. Sadly, [[The Gimp]] did not at the begining. Thus problems with working in CMYK or in bit depths neede for Hollywood work both have been problematic for [[The Gimp]] and its plugins.

Blocking future functionality, I think, is the main thing that Inkscape needs to avoid. As MenTaLguY has said, it's best if plugins were first-class citizens. So what needs to be exposed?

Things off the top of my head:

-Document
|-XML / parse tree
|-view tree

-UI Thingies / dialogs / user interaction

-Utility calls / factories

-- JonCruz

---