Development/Tutorials/Kross/Introduction - Revision history

Yurchor: fix some links

2013-03-23T16:05:01Z

fix some links

Neverendingo: Text replace - "" to ""

2011-06-29T20:52:44Z

Text replace - "</code>" to "</syntaxhighlight>"

Neverendingo: Text replace - "`" to ""`


2011-06-29T20:34:24Z
Text replace - "<code python>" to "<syntaxhighlight lang="python">"

				
				
				
				
			
			← Older revision
			Revision as of 20:34, 29 June 2011
			
Line 166:
Line 166:
  The following Python sample code accesses then the module at runtime and uses the QObject, calls it's slots and properties and connects a signal with a python function (e.g. save as file named "myobjecttest.py" and execute with "kross ./myobjecttest.py");   The following Python sample code accesses then the module at runtime and uses the QObject, calls it's slots and properties and connects a signal with a python function (e.g. save as file named "myobjecttest.py" and execute with "kross ./myobjecttest.py");
    
− <code python> + <syntaxhighlight lang="python">
  #!/usr/bin/env kross   #!/usr/bin/env kross
  import Kross   import Kross
Line 183:
Line 183:
  The [http://websvn.kde.org/trunk/KDE/kdelibs/kross/core/manager.h?view=markup Kross::Manager] class is a singleton that provides access to the interpreters, to actions and to the modules. The Kross::Manager is available within scripting code as module named "Kross". Following Python script uses the Kross module to create a new Kross::Action instance, fills it with JavaScript code and executes that JavaScript code.   The [http://websvn.kde.org/trunk/KDE/kdelibs/kross/core/manager.h?view=markup Kross::Manager] class is a singleton that provides access to the interpreters, to actions and to the modules. The Kross::Manager is available within scripting code as module named "Kross". Following Python script uses the Kross module to create a new Kross::Action instance, fills it with JavaScript code and executes that JavaScript code.
    
− <code python> + <syntaxhighlight lang="python">
  #!/usr/bin/env kross   #!/usr/bin/env kross
  import Kross   import Kross
Line 196:
Line 196:
  The [http://websvn.kde.org/trunk/KDE/kdelibs/kross/core/action.h?view=markup Kross::Action] class offers an abstract container to deal with scripts like a single standalone scriptfile. Each action holds a reference to the by the matching [http://websvn.kde.org/trunk/KDE/kdelibs/kross/core/interpreter.h?view=markup Kross::Interpreter] instance created by [http://websvn.kde.org/trunk/KDE/kdelibs/kross/core/script.h?view=markup Kross::Script] instance. Following Python script accesses the Kross module and the self variable which is our Kross::Action instance that provides the context for the running Python script.   The [http://websvn.kde.org/trunk/KDE/kdelibs/kross/core/action.h?view=markup Kross::Action] class offers an abstract container to deal with scripts like a single standalone scriptfile. Each action holds a reference to the by the matching [http://websvn.kde.org/trunk/KDE/kdelibs/kross/core/interpreter.h?view=markup Kross::Interpreter] instance created by [http://websvn.kde.org/trunk/KDE/kdelibs/kross/core/script.h?view=markup Kross::Script] instance. Following Python script accesses the Kross module and the self variable which is our Kross::Action instance that provides the context for the running Python script.
    
− <code python> + <syntaxhighlight lang="python">
  #!/usr/bin/env kross   #!/usr/bin/env kross
  import Kross   import Kross



Neverendingo: Text replace - "" to ""

2011-06-29T20:29:25Z
Text replace - "<code cppqt>" to "<syntaxhighlight lang="cpp-qt">"

				
				
				
				
			
			← Older revision
			Revision as of 20:29, 29 June 2011
			
Line 115:
Line 115:
    
  Let's take a look at the following code that implements the MyObject class which inherits from QObject;   Let's take a look at the following code that implements the MyObject class which inherits from QObject;
− <code cppqt> + <syntaxhighlight lang="cpp-qt">
  class MyObject : public QObject {   class MyObject : public QObject {
     Q_OBJECT      Q_OBJECT



Jstaniek: /* The Interpreter plugins */
2009-03-07T17:45:51Z
‎The Interpreter plugins

				
				
				
				
			
			← Older revision
			Revision as of 17:45, 7 March 2009
			
Line 38:
Line 38:
  ==The Interpreter plugins==   ==The Interpreter plugins==
    
− Kross offers a plugin-interface to integrate interpreter backends like Python, Ruby and KDE-Javascript. They are loaded on demand at runtime. Neither the application nor Kross needs to know any details about the backends. This clear separation between the application and scripting details enables at the one hand, to deal with scripting at an abstract level without being bound to only one backend, and at the other hand makes it easy to integrate scripting into an already existing application. + Kross offers a ''plugin interface'' to integrate interpreter backends like Python, Ruby and KDE-Javascript. They are loaded on demand at runtime. Neither the application nor Kross needs to know any details about the backends. This clear separation between the application and scripting details enables at the one hand, to deal with scripting at an abstract level without being bound to only one backend, and at the other hand makes it easy to integrate scripting into an already existing application.
    
  Each interpreter plugin needs to implement two abstract classes;   Each interpreter plugin needs to implement two abstract classes;



Jstaniek: /* What Kross is */ grammar
2009-03-07T17:29:18Z
‎What Kross is:  grammar

				
				
				
				
			
			← Older revision
			Revision as of 17:29, 7 March 2009
			
Line 4:
Line 4:
    
  ===What Kross is===   ===What Kross is===
− Kross is a modular scripting framework that provides a complete framework to embed scripting interpreters like Python, Ruby and JavaScript transparently into native applications to bridge the static and dynamic worlds together. + Kross is a modular scripting framework that eases embedding of scripting interpreters like Python, Ruby and JavaScript transparently into native applications to bridge the static and dynamic worlds together.
    
  Scripting interpreters are plugins that are loaded dynamically on demand at runtime by the Kross framework. The application that uses Kross to provide scripting functionality to the user does not need to know anything about the interpreter, itself or any other backend-details. All the application needs to know is that there exists scripting code that should be executed. Kross will then take care of it.   Scripting interpreters are plugins that are loaded dynamically on demand at runtime by the Kross framework. The application that uses Kross to provide scripting functionality to the user does not need to know anything about the interpreter, itself or any other backend-details. All the application needs to know is that there exists scripting code that should be executed. Kross will then take care of it.



Tampakrap at 22:11, 12 October 2008
2008-10-12T22:11:48Z


				
				
				
				
			
			← Older revision
			Revision as of 22:11, 12 October 2008
			
Line 102:
Line 102:
  ===Java===   ===Java===
    
− The [[Projects/Summer_of_Code/2007/Projects/KrossJava|Google Summer of Code 2007]] did provide us the [http://websvn.kde.org/trunk/playground/bindings/krossjava/ krossjava] backend for Java :-) + The [[Projects/Summer_of_Code/2007/Projects/KrossJava|Google Summer of Code 2007]] did provide us the [http://websvn.kde.org/trunk/KDE/kdebindings/java/krossjava/ krossjava] backend for Java :-)
    
  ===Falcon===   ===Falcon===



Tampakrap: /* What Kross is */
2008-02-04T00:41:32Z
‎What Kross is

				
				
				
				
			
			← Older revision
			Revision as of 00:41, 4 February 2008
			
Line 6:
Line 6:
  Kross is a modular scripting framework that provides a complete framework to embed scripting interpreters like Python, Ruby and JavaScript transparently into native applications to bridge the static and dynamic worlds together.   Kross is a modular scripting framework that provides a complete framework to embed scripting interpreters like Python, Ruby and JavaScript transparently into native applications to bridge the static and dynamic worlds together.
    
− Scripting interpreters are plugins that are loaded dynamicly on demand at runtime by the Kross framework. The application that uses Kross to provide scripting functionality to the user does not need to know anything about the interpreter, itself or any other backend-details. All the application needs to know is that there exists scripting code that should be executed. Kross will then take care of it. + Scripting interpreters are plugins that are loaded dynamically on demand at runtime by the Kross framework. The application that uses Kross to provide scripting functionality to the user does not need to know anything about the interpreter, itself or any other backend-details. All the application needs to know is that there exists scripting code that should be executed. Kross will then take care of it.
    
  ===What Kross is not===   ===What Kross is not===



Cbs: /* Advantage of Kross over other solutions */ Made first sentences bold
2008-01-08T02:10:06Z
‎Advantage of Kross over other solutions:  Made first sentences bold

				
				
				
				
			
			← Older revision
			Revision as of 02:10, 8 January 2008
			
Line 24:
Line 24:
    
  ===Advantage of Kross over other solutions===   ===Advantage of Kross over other solutions===
− * Scripting interpreter independent. Kross does not implement an interpreter, it provides access to already existing interpreters. You don't limit your users to a particular scripting language, each user is free to decide which scripting language is best suited. + * '''Scripting interpreter independent.''' Kross does not implement an interpreter, it provides access to already existing interpreters. You don't limit your users to a particular scripting language, each user is free to decide which scripting language is best suited.
− * Real embedding. Rather then communicating with scripting backends e.g. over stdin/stdout or D-Bus Kross does come with plugins that really embed the interpreters and deal with them on the native C/C++ code level to gain optimal performance and flexibility. + * '''Real embedding.''' Rather then communicating with scripting backends e.g. over stdin/stdout or D-Bus Kross does come with plugins that really embed the interpreters and deal with them on the native C/C++ code level to gain optimal performance and flexibility.
− * Kross is fast. Kross had a bit of luck to be adopted by Krita so early since one of the top-priorities Krita had on a scripting backend was performance. During the years we managed to increase the speed to a level where it's hard to see a difference to native in C/C++ written code. + * '''Kross is fast.''' Kross had a bit of luck to be adopted by Krita so early since one of the top-priorities Krita had on a scripting backend was performance. During the years we managed to increase the speed to a level where it's hard to see a difference to native in C/C++ written code.
− * Kross was designed from the beginning with platform-independence in mind. This is the result of the origins of Kross - it started as Kexi plugin, and Kexi itself runs at least on Linux, Windows and Mac since it's early days. + * '''Kross is platform-independent.''' From the beginning Kross was designed with platform-independence in mind. This is the result of the origins of Kross - it started as Kexi plugin, and Kexi itself runs at least on Linux, Windows and Mac since it's early days.
− * Kross is stable and well proven. Before Kross finally landed in kdelibs it was in use in KOffice for 3 major releases and was thus "tested" by a wide range of users worldwide. + * '''Kross is stable and well proven.''' Before Kross finally landed in kdelibs it was in use in KOffice for 3 major releases and was thus "tested" by a wide range of users worldwide.
− * A lot of documentation, scripts and applications are using Kross already today. The latter guarantees that Kross offers the solution for many scenarios. + * '''A lot of documentation, scripts and applications are using Kross already today.''' The latter guarantees that Kross offers the solution for many scenarios.
− * Kross could be easily extended with a new scripting interpreter. There are no changes needed to the applications. So, whatever hype we are able to see in the next few years, we are ready to fullfit the possible user-requests for them without much pain. + * '''Kross can be easily extended with a new scripting interpreter.''' There are no changes needed to the applications. So, whatever hype we are able to see in the next few years, we are ready to fullfit the possible user-requests for them without much pain.
− * The synergy-effect if multiple applications are sharing the same interpreter plugin implementations ensures that bugs are discovered and fixed as soon as possible. Also each app is able to profit if someone writes for example a plugin for the LUA-interpreter each app is able to use the new backend without any recompile. + * '''Kross benefits from applications.''' The synergy-effect if multiple applications are sharing the same interpreter plugin implementations ensures that bugs are discovered and fixed as soon as possible. Also each app is able to profit if someone writes for example a plugin for the LUA-interpreter each app is able to use the new backend without any recompile.
− * Kross does reuse existing technologies as much as possible. There is no need for code-generation at compile time and no new "bindings API" is introduced since we are reusing the Qt Meta-Object System. You are able to throw in a QObject and a script is able to connect with the signals, call slots as there are functions, access enumerations, get/set properties or pass QObject/QWidget instances around as there are classes. + * '''Kross reuses existing technologies as much as possible.''' There is no need for code-generation at compile time and no new "bindings API" is introduced since we are reusing the Qt Meta-Object System. You are able to throw in a QObject and a script is able to connect with the signals, call slots as there are functions, access enumerations, get/set properties or pass QObject/QWidget instances around as there are classes.
− * The interpreter backend is very flexible since each interpreter's plugin is able to decide on its own how to implement the bridging functionality. If you like for example to have it more "pythonic" by using the decorators introduced in Python 2.4, you are free to implement it and each app that uses Kross will profit by beeing able to use such decorators from now on. + * '''The interpreter backend is very flexible.''' Each interpreter's plugin is able to decide on its own how to implement the bridging functionality. If you like for example to have it more "pythonic" by using the decorators introduced in Python 2.4, you are free to implement it and each app that uses Kross will profit by beeing able to use such decorators from now on.
− * Kross will stay backward-compatible because as part of kdelibs it needs to follow strict policies and needs to provide backward-compatibility at least during the lifetime of KDE4. + * '''Kross will stay backward-compatible.''' Kross is part of kdelibs and thus follows strict policies to provide backward-compatibility at least during the lifetime of KDE4.
    
  ==The Interpreter plugins==   ==The Interpreter plugins==



Cbs: /* Advantage of Kross over other solutions */ tried to remove user==male assumption from text and made some minor editorial changes
2008-01-08T01:56:24Z
‎Advantage of Kross over other solutions:  tried to remove user==male assumption from text and made some minor editorial changes

				
				
				
				
			
			← Older revision
			Revision as of 01:56, 8 January 2008
			
Line 24:
Line 24:
    
  ===Advantage of Kross over other solutions===   ===Advantage of Kross over other solutions===
− * Scripting interpreter independend. Kross does not implement an interpreter by it's own rather then providing access to already existing solutions. You don't have to decide for your user what scripting language he should use, let him decide and keep him happy and productive that way! + * Scripting interpreter independent. Kross does not implement an interpreter, it provides access to already existing interpreters. You don't limit your users to a particular scripting language, each user is free to decide which scripting language is best suited.
  * Real embedding. Rather then communicating with scripting backends e.g. over stdin/stdout or D-Bus Kross does come with plugins that really embed the interpreters and deal with them on the native C/C++ code level to gain optimal performance and flexibility.   * Real embedding. Rather then communicating with scripting backends e.g. over stdin/stdout or D-Bus Kross does come with plugins that really embed the interpreters and deal with them on the native C/C++ code level to gain optimal performance and flexibility.
− * Kross is damn fast. Kross had a bit of luck to be adopted by Krita so early since one of the top-priorities Krita had on a scripting backend was performance. During the years we got it managed to increase the speed to a level where it's hard to see a difference to native in C/C++ written code. + * Kross is fast. Kross had a bit of luck to be adopted by Krita so early since one of the top-priorities Krita had on a scripting backend was performance. During the years we managed to increase the speed to a level where it's hard to see a difference to native in C/C++ written code.
− * Kross was designed from the beginning with platform-independency in mind. This is the result of the origins of Kross - it started as Kexi plugin, and Kexi itself runs at least on Linux, Windows and Mac since it's early days. + * Kross was designed from the beginning with platform-independence in mind. This is the result of the origins of Kross - it started as Kexi plugin, and Kexi itself runs at least on Linux, Windows and Mac since it's early days.
− * Kross is stable and well proven because before it finally landed in kdelibs it was in use in KOffice for 3 major releases and was thus "tested" by a wide range of users worldwide. + * Kross is stable and well proven. Before Kross finally landed in kdelibs it was in use in KOffice for 3 major releases and was thus "tested" by a wide range of users worldwide.
− * There exists a bunch of documentations, scripts and applications that are using Kross already today. The latter guarantees that Kross offers the solution for many scenarios. + * A lot of documentation, scripts and applications are using Kross already today. The latter guarantees that Kross offers the solution for many scenarios.
− * Kross could be easily extended with a new scripting interpreter. There are no changes needed at the applications. So, whatever hype we are able to see next few years, we are ready to fullfit the possible user-requests for them without much pain. + * Kross could be easily extended with a new scripting interpreter. There are no changes needed to the applications. So, whatever hype we are able to see in the next few years, we are ready to fullfit the possible user-requests for them without much pain.
  * The synergy-effect if multiple applications are sharing the same interpreter plugin implementations ensures that bugs are discovered and fixed as soon as possible. Also each app is able to profit if someone writes for example a plugin for the LUA-interpreter each app is able to use the new backend without any recompile.   * The synergy-effect if multiple applications are sharing the same interpreter plugin implementations ensures that bugs are discovered and fixed as soon as possible. Also each app is able to profit if someone writes for example a plugin for the LUA-interpreter each app is able to use the new backend without any recompile.
− * Kross does reuse existing technologies as much as possible. There is no need for code-generation at compile time and no own "bindings API" is introduced since we are reusing the Qt Meta-Object System. You are able to throw in a QObject and a script is able to connect with the signals, call slots as there are functions, access enumerations, get/set properties or pass QObject/QWidget instances around as there are classes. + * Kross does reuse existing technologies as much as possible. There is no need for code-generation at compile time and no new "bindings API" is introduced since we are reusing the Qt Meta-Object System. You are able to throw in a QObject and a script is able to connect with the signals, call slots as there are functions, access enumerations, get/set properties or pass QObject/QWidget instances around as there are classes.
− * The interpreter backend is very flexible since each interpreter's plugin is able to decide by it's own how to implement the bridging functionality. If you like for example to have it more "pythonic" by using the with Python 2.4  introduced decorators, you are free to implement it and each app that uses Kross will profit by beeing able to use such decorators from now on. + * The interpreter backend is very flexible since each interpreter's plugin is able to decide on its own how to implement the bridging functionality. If you like for example to have it more "pythonic" by using the decorators introduced in Python 2.4, you are free to implement it and each app that uses Kross will profit by beeing able to use such decorators from now on.
  * Kross will stay backward-compatible because as part of kdelibs it needs to follow strict policies and needs to provide backward-compatibility at least during the lifetime of KDE4.   * Kross will stay backward-compatible because as part of kdelibs it needs to follow strict policies and needs to provide backward-compatibility at least during the lifetime of KDE4.

@@ Line 147: / Line 147: @@
+   }
+}
-</code>
+</syntaxhighlight>
 At the bottom the krossmodule() function will be called by Kross and returns an instance of MyObject that is then exposed to the scripting backend.
@@ Line 177: / Line 177: @@
 obj1.setParent(m)
 print "%s %s" % (obj1.name,obj1.parent().name)
-</code>
+</syntaxhighlight>
 ==Manager, GuiClient, Action==
@@ Line 190: / Line 190: @@
 a.setCode("println(\"Hello world from Kjs\");")
 a.trigger()
-</code>
+</syntaxhighlight>
 The [http://websvn.kde.org/trunk/KDE/kdelibs/kross/core/guiclient.h?view=markup Kross::GuiClient] class implements KXMLGUIClient to provide GUI functionality, handling of XML configuration files on a more abstract level and offers some predefined actions that could be optionally used in your application.
@@ Line 208: / Line 208: @@
 print "description=%s" % self.description()
 print "code=%s" % self.code()
-</code>
+</syntaxhighlight>
 ==D-Bus and Kross==