Development/Tutorials/Kross/Introduction: Difference between revisions

    From KDE TechBase
    m (Correct some "it's" to "its".)
    (28 intermediate revisions by 10 users not shown)
    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 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===
    Kross does not implement an own scripting language rather then providing access to already existing solutions. Kross does not implement a complete Toolkit-binding rather providing access to already existing solutions like PyQt/PyKDE or TkInter for Python or Korundum/QtRuby for Ruby. Kross does not auto-generate code, it is not needed to maintain any configurationfiles and Kross does not come with yet another own bindings-API. All it does is to connect things transparently together and to offer optional access to already existing technologies.
    Kross does not implement its own scripting language, rather, it provides access to already existing solutions. Kross does not implement a complete Toolkit-binding, rather, it provides access to already existing solutions like PyQt/PyKDE or TkInter for Python or Korundum/QtRuby for Ruby. Kross does not auto-generate code, it is not needed to maintain any configuration files, and it does not come with yet another bindings-API. All it does is to connect things transparently together and to offer optional access to already existing technologies.


    ===Reuse and choice are the goals===
    ===Reuse and choice are the goals===
    There exist a wide range of solutions to deal with scripting. Languages like Python did enjoyed years of evolution, a large community around them with 3rd-party modules for nearly everything exist. Same goes for a bunch of other languages where sometimes a specialy functionality is only available for some of them and where each language comes with it's own way of doing things. Each user has an own preference for what scripting language he likes to use and maybe even already collected skills in some specific areas.
    There exists a wide range of solutions to deal with scripting. Programming languages like Python have enjoyed years of evolution and a large community around them with 3rd-party modules for nearly everything. The same goes for a lot of other languages where there sometimes exists a special function that is only available to a particular language, and where each language comes with its own way of doing things. Each user may have their own preference for what scripting language they like to use, and over time, may have acquired skills in some specific areas.


    Rather then limiting us and our users to only one specific language with it's own way of doing things, Kross does offer a flexible way to be optional able to support all of them without additional code and maintaining work at the application level. To allow the user to choose what he likes and knows most does limit the entry-barrier to get his things done and even to be able to contribute own solutions significantly.
    Rather than limiting users to only one specific language with its own way of doing things, Kross offers a flexible way of supporting multiple programming languages without additional code and maintenance work, at the application level. Kross allows the user to choose what they like and know the most, and it minimizes the entry-barrier to get his things done and to be able to contribute to one's own solutions significantly.


    ===Supported interpreters===
    ===Supported interpreters===
    As of today Python, Ruby and JavaScript are supported. While all of them are passing the unittests, current state is, that Python is the most complete one followed by Ruby which is near the same state and finally JavaScript which needs some more tweaks to be as rock-stable as the other both implementations.
    As of today Python, Ruby and JavaScript are supported. While all of them are passing the unittests, current state is, that Python is the most complete one followed by Ruby which is near the same state and finally JavaScript which needs some more tweaks to be as rock-stable as the other both implementations.


    Support for Java is on progress in playground/bindings/krossjava.
    Work on progress are krossjava (thanks to google for supporting this plugin within the Google Summer of Code 2007) that implements support for the Java Virtual Machine and krossfalcon that implements support for The Falcon Programming Language.


    For sure any interpreter-plugin you may like to implement is very welcome. At the end the open source world is about choices :)
    For sure any interpreter-plugin you may like to implement is very welcome. At the end the open source world is about choices :)


    ===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 DBus 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 origin of Kross which started initial 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 its early days.
    * Kross is stable and well proven cause before it finally landed in kdelibs it was in use in KOffice for 3 major releases and was that way "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 later one guaranteed that Kross offers the solution for a wide range of use-case 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 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 code-generation at compiletime needed 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 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.
    * Unlimit flexibility of the interpreter backend since each interpreter-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 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 cause 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==


    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;
    <ul>
    * The [https://projects.kde.org/projects/kde/kdelibs/repository/revisions/master/entry/kross/coreinterpreter.h Kross::Interpreter] class is a singleton controlled by the    [https://projects.kde.org/projects/kde/kdelibs/repository/revisions/master/entry/kross/coremanager.h Kross::Manager] and could be used to setup the interpreter or do other things to share functionality between instances of the Script class.
      <li>The [http://websvn.kde.org/trunk/KDE/kdelibs/kross/core/interpreter.h?view=markup Kross::Interpreter] class is a singleton controlled by the    [http://websvn.kde.org/trunk/KDE/kdelibs/kross/core/manager.h?view=markup Kross::Manager] and could be used to setup the interpreter or do other things to share functionality between instances of the Script class.</li>
    * The [https://projects.kde.org/projects/kde/kdelibs/repository/revisions/master/entry/kross/corescript.h Kross::Script] class handles exactly one script instance. An application is able to deal with multiple scripts at the same time where each of them has its own instance of the Kross::Script class controlled by an instance of the more abstract [https://projects.kde.org/projects/kde/kdelibs/repository/revisions/master/entry/kross/coreaction.h Kross::Action] class.
      <li>The [http://websvn.kde.org/trunk/KDE/kdelibs/kross/core/script.h?view=markup Kross::Script] class handles exactly one script instance. An application is able to deal with multiple scripts at the same time where each of them has it's own instance of the Kross::Script class controlled by an instance of the more abstract [http://websvn.kde.org/trunk/KDE/kdelibs/kross/core/action.h?view=markup Kross::Action] class.</li>
    </ul>


    ===Python===
    ===Python===
    Line 50: Line 48:
    The [http://websvn.kde.org/trunk/KDE/kdebindings/python/krosspython/ Python plugin] implements access to the [http://www.python.org/ Python] scripting language.
    The [http://websvn.kde.org/trunk/KDE/kdebindings/python/krosspython/ Python plugin] implements access to the [http://www.python.org/ Python] scripting language.


    The [http://websvn.kde.org/trunk/KDE/kdelibs/kross/test/unittest.py?view=markup unittest.py] Python script file implements unittests for common functionality. For the unittests kross does use a special test-application that got compiled if cmake -DKDE4_BUILD_TESTS=1 was used for kdelibs. You are able to run the unittest with
    The [https://projects.kde.org/projects/kde/kdelibs/repository/revisions/master/entry/kross/test/unittest.py unittest.py] Python script file implements unittests for common functionality. For the unittests kross does use a special test-application that got compiled if cmake -DKDE4_BUILD_TESTS=1 was used for kdelibs. You are able to run the unittest with
    <pre>
    <pre>
    cd kdelibs/kross/test
    cd kdelibs/kross/test
    Line 56: Line 54:
    </pre>
    </pre>


    The [http://websvn.kde.org/trunk/KDE/kdelibs/kross/test/testkross.py?view=markup testkross.py] Python script file demonstrates how to use Kross to execute some JavaScript code within a python script.
    Other scripts are...
    <pre>
    * The [https://projects.kde.org/projects/kde/kdelibs/repository/revisions/master/entry/kross/test/testkross.py testkross.py] Python script file demonstrates how to use Kross to execute some JavaScript code within a python script.
    import Kross
    * The [https://projects.kde.org/projects/kde/kdelibs/repository/revisions/master/entry/kross/test/testguitk.py testguitk.py] Python script file that creates and displays a modal dialog using the TkInter GUI-toolkit.
    kjsaction = Kross.action("MyKjsScript")
    * The [https://projects.kde.org/projects/kde/kdelibs/repository/revisions/master/entry/kross/test/testguiqt.py testguiqt.py] Python script file shows how to use PyQt while the [https://projects.kde.org/projects/kde/kdelibs/repository/revisions/master/entry/kross/test/testguiform.py testguiform.py] uses the Kross Form module.
    kjsaction.setInterpreter("javascript")
    kjsaction.setCode( "println(\"Hello world from Kjs\");" )
    kjsaction.trigger()
    </pre>
    Other scripts are the [http://websvn.kde.org/trunk/KDE/kdelibs/kross/test/testguitk.py?view=markup testguitk.py] Python script file that creates and displays a modal dialog using the TkInter GUI-toolkit. The [http://websvn.kde.org/trunk/KDE/kdelibs/kross/test/testguiqt.py?view=markup testguiqt.py] Python script file shows how to use PyQt while the [http://websvn.kde.org/trunk/KDE/kdelibs/kross/test/testguiform.py?view=markup testguiform.py] uses the Kross Form module.


    * The [http://websvn.kde.org/trunk/KDE/kdebindings/python/krosspython/pythoninterpreter.h?view=markup Kross::PythonInterpreter] class implements [http://websvn.kde.org/trunk/KDE/kdelibs/kross/core/interpreter.h?view=markup Kross::Interpreter] for the Python interpreter backend and implements the createScript factory method to create [http://websvn.kde.org/trunk/KDE/kdebindings/python/krosspython/pythonscript.h?view=markup Kross::PythonScript] instances.
    The krosspython plugin consists of...
    *  The [http://websvn.kde.org/trunk/KDE/kdebindings/python/krosspython/pythonscript.h?view=markup Kross::PythonScript] class implements [http://websvn.kde.org/trunk/KDE/kdelibs/kross/core/script.h?view=markup Kross::Script] for the Python backend to provide the functionality to execute Python code within a script-container.
    * The [http://websvn.kde.org/trunk/KDE/kdebindings/python/krosspython/pythoninterpreter.h Kross::PythonInterpreter] class implements [https://projects.kde.org/projects/kde/kdelibs/repository/revisions/master/entry/kross/coreinterpreter.h Kross::Interpreter] for the Python interpreter backend and implements the createScript factory method to create [http://websvn.kde.org/trunk/KDE/kdebindings/python/krosspython/pythonscript.h Kross::PythonScript] instances.
    * The [http://websvn.kde.org/trunk/KDE/kdebindings/python/krosspython/pythonmodule.h?view=markup Kross::PythonModule] class is the __main__ Python environment used as global object namespace. This module is shared between the different [http://websvn.kde.org/trunk/KDE/kdebindings/python/krosspython/pythonscript.h?view=markup Kross::PythonScript] instances which run in there own module namespace. The [http://websvn.kde.org/trunk/KDE/kdebindings/python/krosspython/pythonmodule.h?view=markup Kross::PythonModule] also spends access to the the whole Kross functionality and manages all the @a Kross::PythonExtension modules.
    *  The [http://websvn.kde.org/trunk/KDE/kdebindings/python/krosspython/pythonscript.h Kross::PythonScript] class implements [https://projects.kde.org/projects/kde/kdelibs/repository/revisions/master/entry/kross/corescript.h Kross::Script] for the Python backend to provide the functionality to execute Python code within a script-container.
    * The [http://websvn.kde.org/trunk/KDE/kdebindings/python/krosspython/pythonextension.h?view=markup Kross::PythonExtension] class implements a Py::Object to wrap a QObject instance into the world of Python.
    * The [http://websvn.kde.org/trunk/KDE/kdebindings/python/krosspython/pythonmodule.h Kross::PythonModule] class is the __main__ Python environment used as global object namespace. This module is shared between the different [http://websvn.kde.org/trunk/KDE/kdebindings/python/krosspython/pythonscript.h Kross::PythonScript] instances which run in there own module namespace. The [http://websvn.kde.org/trunk/KDE/kdebindings/python/krosspython/pythonmodule.h Kross::PythonModule] also spends access to the the whole Kross functionality and manages all the @a Kross::PythonExtension modules.
    * Within [http://websvn.kde.org/trunk/KDE/kdebindings/python/krosspython/pythonvariant.h?view=markup Kross::PythonVariant] the Kross::PythonType helper class is used to cast
    * The [http://websvn.kde.org/trunk/KDE/kdebindings/python/krosspython/pythonextension.h Kross::PythonExtension] class implements a Py::Object to wrap a QObject instance into the world of Python.
    between QVariant and Py::Object values while the Kross::PythonMetaTypeFactory helper class is used as factory within [http://websvn.kde.org/trunk/KDE/kdebindings/python/krosspython/pythonextension.h?view=markup Kross::PythonExtension] to translate an argument into a Kross::MetaType needed for QGenericArgument's data pointer.
    * Within [http://websvn.kde.org/trunk/KDE/kdebindings/python/krosspython/pythonvariant.h Kross::PythonVariant] the Kross::PythonType helper class is used to cast between QVariant and Py::Object values while the Kross::PythonMetaTypeFactory helper class is used as factory within [http://websvn.kde.org/trunk/KDE/kdebindings/python/krosspython/pythonextension.h Kross::PythonExtension] to translate an argument into a Kross::MetaType needed for QGenericArgument's data pointer.


    ===Ruby===
    ===Ruby===
    Line 77: Line 70:
    The [http://websvn.kde.org/trunk/KDE/kdebindings/ruby/krossruby/ Ruby plugin] implements access to the [http://www.ruby-lang.org/ Ruby] scripting language.
    The [http://websvn.kde.org/trunk/KDE/kdebindings/ruby/krossruby/ Ruby plugin] implements access to the [http://www.ruby-lang.org/ Ruby] scripting language.


    The [http://websvn.kde.org/trunk/KDE/kdelibs/kross/test/unittest.rb?view=markup unittest.rb] Ruby script file implements unittests for common functionality. For the unittests kross does use a special test-application that got compiled if cmake -DKDE4_BUILD_TESTS=1 was used for kdelibs. You are able to run the unittest with
    The [https://projects.kde.org/projects/kde/kdelibs/repository/revisions/master/entry/kross/test/unittest.rb unittest.rb] Ruby script file implements unittests for common functionality. For the unittests kross does use a special test-application that got compiled if cmake -DKDE4_BUILD_TESTS=1 was used for kdelibs. You are able to run the unittest with
    <pre>
    <pre>
    cd kdelibs/kross/test
    cd kdelibs/kross/test
    Line 83: Line 76:
    </pre>
    </pre>


    * The [http://websvn.kde.org/trunk/KDE/kdebindings/ruby/krossruby/rubyinterpreter.h?view=markup Kross::RubyInterpreter] class implements [http://websvn.kde.org/trunk/KDE/kdelibs/kross/core/interpreter.h?view=markup Kross::Interpreter] for the Ruby interpreter backend and provides with the createScript a factory method to create [http://websvn.kde.org/trunk/KDE/kdebindings/ruby/krossruby/rubyscript.h?view=markup Kross::RubyScript] instances.
    The krossruby plugin consists of...
    * The [http://websvn.kde.org/trunk/KDE/kdebindings/ruby/krossruby/rubyscript.h?view=markup Kross::RubyScript] class implements [http://websvn.kde.org/trunk/KDE/kdelibs/kross/core/script.h?view=markup Kross::Script] for the Ruby backend to provide the functionality to execute Ruby code within a script-container.
    * The [http://websvn.kde.org/trunk/KDE/kdebindings/ruby/krossruby/rubyinterpreter.h Kross::RubyInterpreter] class implements [https://projects.kde.org/projects/kde/kdelibs/repository/revisions/master/entry/kross/coreinterpreter.h Kross::Interpreter] for the Ruby interpreter backend and provides with the createScript a factory method to create [http://websvn.kde.org/trunk/KDE/kdebindings/ruby/krossruby/rubyscript.h Kross::RubyScript] instances.
    * The [http://websvn.kde.org/trunk/KDE/kdebindings/ruby/krossruby/rubymodule.h?view=markup Kross::RubyModule] class is the __main__ Ruby environment used as global object namespace. This module is shared between the different [http://websvn.kde.org/trunk/KDE/kdebindings/ruby/krossruby/rubyscript.h?view=markup Kross::RubyScript] instances which run in there own module namespace. The [http://websvn.kde.org/trunk/KDE/kdebindings/ruby/krossruby/rubymodule.h?view=markup Kross::RubyModule] also spends access to the the whole Kross functionality and manages all the @a Kross::RubyExtension modules.
    * The [http://websvn.kde.org/trunk/KDE/kdebindings/ruby/krossruby/rubyscript.h Kross::RubyScript] class implements [https://projects.kde.org/projects/kde/kdelibs/repository/revisions/master/entry/kross/corescript.h Kross::Script] for the Ruby backend to provide the functionality to execute Ruby code within a script-container.
    * The [http://websvn.kde.org/trunk/KDE/kdebindings/ruby/krossruby/rubyextension.h?view=markup Kross::RubyExtension] class implements a Ruby VALUE object to wrap a
    * The [http://websvn.kde.org/trunk/KDE/kdebindings/ruby/krossruby/rubymodule.h Kross::RubyModule] class is the __main__ Ruby environment used as global object namespace. This module is shared between the different [http://websvn.kde.org/trunk/KDE/kdebindings/ruby/krossruby/rubyscript.h Kross::RubyScript] instances which run in there own module namespace. The [http://websvn.kde.org/trunk/KDE/kdebindings/ruby/krossruby/rubymodule.h Kross::RubyModule] also spends access to the the whole Kross functionality and manages all the @a Kross::RubyExtension modules.
    QObject instance into the world of Ruby.
    * The [http://websvn.kde.org/trunk/KDE/kdebindings/ruby/krossruby/rubyextension.h Kross::RubyExtension] class implements a Ruby VALUE object to wrap a QObject instance into the world of Ruby.
    * Within [http://websvn.kde.org/trunk/KDE/kdebindings/ruby/krossruby/rubyvariant.h?view=markup Kross::RubyVariant] the Kross::RubyType helper class is used to cast
    * Within [http://websvn.kde.org/trunk/KDE/kdebindings/ruby/krossruby/rubyvariant.h Kross::RubyVariant] the Kross::RubyType helper class is used to cast between QVariant and Ruby VALUE values while the Kross::RubyMetaTypeFactory helper class is used as factory within [http://websvn.kde.org/trunk/KDE/kdebindings/ruby/krossruby/rubyextension.h Kross::RubyExtension] to translate an argument into a Kross::MetaType needed for QGenericArgument's data pointer.
    between QVariant and Ruby VALUE values while the Kross::RubyMetaTypeFactory helper class is used as factory within [http://websvn.kde.org/trunk/KDE/kdebindings/ruby/krossruby/rubyextension.h?view=markup Kross::RubyExtension] to translate an argument into a Kross::MetaType needed for QGenericArgument's data pointer.


    ===JavaScript===
    ===JavaScript===


    The [http://websvn.kde.org/trunk/KDE/kdelibs/kross/kjs KDE JavaScript plugin] uses the in kdelibs4 included Kjs and KjsEmbed4 frameworks to provide access to the JavaScript language.
    The [https://projects.kde.org/projects/kde/kdelibs/repository/revisions/master/entry/kross/kjs KDE JavaScript plugin] uses the in kdelibs4 included Kjs and KjsEmbed4 frameworks to provide access to the JavaScript language.


    The [http://websvn.kde.org/trunk/KDE/kdelibs/kross/test/unittest.js?view=markup unittest.js] KDE-JavaScript script file implements unittests for common functionality. For the unittests kross does use a special test-application that got compiled if cmake -DKDE4_BUILD_TESTS=1 was used for kdelibs. You are able to run the unittest with
    The [https://projects.kde.org/projects/kde/kdelibs/repository/revisions/master/entry/kross/test/unittest.js unittest.js] KDE-JavaScript script file implements unittests for common functionality. For the unittests kross does use a special test-application that got compiled if cmake -DKDE4_BUILD_TESTS=1 was used for kdelibs. You are able to run the unittest with
    <pre>
    <pre>
    cd kdelibs/kross/test
    cd kdelibs/kross/test
    Line 102: Line 94:


    For details about KDE-JavaScript see...
    For details about KDE-JavaScript see...
    * [http://websvn.kde.org/trunk/KDE/kdelibs/kjs/README?view=markup Kjs readme]
    * [http://websvn.kde.org/trunk/KDE/kdelibs/kjs/README Kjs readme]
    * [http://websvn.kde.org/trunk/KDE/kdelibs/kjs/ Kjs svn]
    * [http://websvn.kde.org/trunk/KDE/kdelibs/kjs/ Kjs svn]
    * [http://xmelegance.org/kjsembed KjsEmbed home]
    * [http://xmelegance.org/kjsembed KjsEmbed home]
    Line 110: Line 102:
    ===Java===
    ===Java===


    Within the [http://code.google.com/soc/kde/appinfo.html?csaid=677EEEE26D2CB937 Google Summer of Code] the [http://websvn.kde.org/trunk/playground/bindings/krossjava/ krossjava] should provide us a 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===


    So, this is work in progress.
    The [http://websvn.kde.org/trunk/playground/bindings/krossfalcon/ krossfalcon] plugin does implement access to [http://www.falconpl.org The Falcon Programming Language].


    ==The Module plugins==
    ==The Module plugins==
    Line 118: Line 112:
    Modules are plugins loaded on demand at runtime to provide additional functionality. They only provide a factory to create and return a QObject instance that is then exposed to the scripting backend.
    Modules are plugins loaded on demand at runtime to provide additional functionality. They only provide a factory to create and return a QObject instance that is then exposed to the scripting backend.


    Since Qt's introspection functionality is used, we are able to throw in just QObject's and have them act as classes/objects within a scripting backend. Slots are membermethods while properties and enumerations are membervariables. If your application also likes to offer [http://hal.freedesktop.org/wiki/Software/dbus DBus] support it may be an idea to reuse the [http://doc.trolltech.com/4.2/qdbusabstractadaptor.html QDBusAbstractAdaptor] implementations your application has also for scripting, like for example [[Development/Tutorials/KSpread_Scripting|KSpread]] did.
    Since Qt's introspection functionality is used, we are able to throw in just {{qt|QObject}}'s and have them act as classes/objects within a scripting backend. Slots are membermethods while properties and enumerations are membervariables. If your application also likes to offer [http://hal.freedesktop.org/wiki/Software/dbus D-Bus] support it may be an idea to reuse the {{qt|QDBusAbstractAdaptor}} implementations your application has also for scripting, like for example [[Development/Tutorials/KSpread_Scripting|KSpread]] did.


    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;
    <pre>
    <syntaxhighlight lang="cpp-qt">
    class MyObject : public QObject {
    class MyObject : public QObject {
       Q_OBJECT
       Q_OBJECT
    Line 149: Line 143:


    extern "C" {
    extern "C" {
       QObject* krossmodule() {
       KDE_EXPORT QObject* krossmodule() {
         return new MyObject();
         return new MyObject();
       }
       }
    }
    }
    </pre>
    </syntaxhighlight>
    At the bottom the krossmodule() function will be called by Kross and returns an instance of MyObject.
    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.


    Then we just need to have our myobject.h and myobject.cpp files, filled with the content above, defined in the CMakeLists.txt file. The library needs to be named "krossmodule..." where the "..." is then the name the module is accessible as. For our example we use "krossmodulemyobjectmod" and therefore we are able to access the module if installed as "myobjectmod". The example does not depend on Kross, so you may like to replace ${KROSS_INCLUDES} with whatever else your module depends on.
    Then we just need to have our myobject.h and myobject.cpp files, filled with the content above, defined in the CMakeLists.txt file. The library needs to be named "krossmodule..." where the "..." is then the name the module is accessible as. For our example we use "krossmodulemyobjectmod" and therefore we are able to access the module if installed as "myobjectmod". The example does not depend on Kross, so you may like to replace ${KROSS_INCLUDES} with whatever else your module depends on.
    Line 162: Line 156:
    set(krossmodulemyobjectmod_PART_SRCS
    set(krossmodulemyobjectmod_PART_SRCS
       myobject.cpp)
       myobject.cpp)
    kde4_automoc(${krossmodulemyobjectmod_PART_SRCS})
    kde4_add_plugin(krossmodulemyobjectmod
    kde4_add_plugin(krossmodulemyobjectmod
       ${krossmodulemyobjectmod_PART_SRCS})
       ${krossmodulemyobjectmod_PART_SRCS})
    Line 171: Line 164:
    </pre>
    </pre>


    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 its 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");


    <pre>
    <syntaxhighlight lang="python">
    #!/usr/bin/env kross
    #!/usr/bin/env kross
    import Kross
    import Kross
    Line 184: Line 177:
    obj1.setParent(m)
    obj1.setParent(m)
    print "%s %s" % (obj1.name,obj1.parent().name)
    print "%s %s" % (obj1.name,obj1.parent().name)
    </pre>
    </syntaxhighlight>


    ==Manager, GuiClient, Action==
    ==Manager, GuiClient, Action==


    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 [https://projects.kde.org/projects/kde/kdelibs/repository/revisions/master/entry/kross/coremanager.h 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.


    <pre>
    <syntaxhighlight lang="python">
    #!/usr/bin/env kross
    #!/usr/bin/env kross
    import Kross
    import Kross
    Line 197: Line 190:
    a.setCode("println(\"Hello world from Kjs\");")
    a.setCode("println(\"Hello world from Kjs\");")
    a.trigger()
    a.trigger()
    </pre>
    </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.
    The [https://projects.kde.org/projects/kde/kdelibs/repository/revisions/master/entry/kross/coreguiclient.h 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.


    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 [https://projects.kde.org/projects/kde/kdelibs/repository/revisions/master/entry/kross/coreaction.h 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 [https://projects.kde.org/projects/kde/kdelibs/repository/revisions/master/entry/kross/coreinterpreter.h Kross::Interpreter] instance created by [https://projects.kde.org/projects/kde/kdelibs/repository/revisions/master/entry/kross/corescript.h 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.


    <pre>
    <syntaxhighlight lang="python">
    #!/usr/bin/env kross
    #!/usr/bin/env kross
    import Kross
    import Kross
    Line 215: Line 208:
    print "description=%s" % self.description()
    print "description=%s" % self.description()
    print "code=%s" % self.code()
    print "code=%s" % self.code()
    </pre>
    </syntaxhighlight>


    ==DBus and Kross==
    ==D-Bus and Kross==


    With the [http://doc.trolltech.com/4.2/qtdbus.html QtDBus module] Qt provides a library that a Qt/KDE application is able to use to make Inter-Process Communication using the [http://dbus.freedesktop.org D-BUS protocol].
    With the [http://doc.trolltech.com/4.2/qtdbus.html QtDBus module] Qt provides a library that a Qt/KDE application is able to use to make Inter-Process Communication using the [http://dbus.freedesktop.org D-BUS protocol].


    The QtDBus module uses the Qt Signals and Slots mechanism. Applications that like to provide parts of there functionality to the DBus world are able to do so by implementing classes that inherit from the [http://doc.trolltech.com/4.2/qdbusabstractadaptor.html QDBusAbstractAdaptor] class.
    The QtDBus module uses the Qt Signals and Slots mechanism. Applications that like to provide parts of their functionality to the D-Bus world are able to do so by implementing classes that inherit from the {{qt|QDBusAbstractAdaptor}} class.


    Kross is able to reuse such by an application provided bindings. So, once your application supports dbus, Kross is able to reuse those already existing code and offers transparent access to the scripting-backends to them. How does this differ from e.g. the python-dbus package? Well, first method-calls don't go through the dbus-socket and then it's not dbus-related at all except, that we are able to reuse what your application offers anyway: a clean interface to the outside world. But that's not all, we are not limited to what's possible with dbus. We are also able to exchange instance-pointers to QObject or QWidget instances.
    Kross is able to reuse such by an application provided bindings. So, once your application supports D-Bus, Kross is able to reuse those already existing code and offers transparent access to the scripting-backends to them. How does this differ from e.g. the python-dbus package? Well, first method-calls don't go through the dbus-socket and then it's not dbus-related at all except, that we are able to reuse what your application offers anyway: a clean interface to the outside world. But that's not all, we are not limited to what's possible with D-Bus. We are also able to exchange instance-pointers to QObject or QWidget instances.


    For an example you may like to take a look at how it was done in the KSpread [http://websvn.kde.org/trunk/koffice/kspread/plugins/scripting/ScriptingModule.cpp?view=markup ScriptingModule] class.
    For an example you may like to take a look at how it was done in the Calligra Sheets [https://projects.kde.org/projects/calligra/repository/revisions/master/entry/sheets/plugins/scripting/ScriptingModule.cpp ScriptingModule] class.

    Revision as of 12:59, 15 April 2014

    Introduction

    The Kross scripting framework provides full Python, Ruby and KDE JavaScript scripting support. The goal was to limit the work needed on applications to have them fully scriptable and to provide a modular way to transparently integrate additional interpreters and in that way extend your application with a new scripting-backend without any new line of code and even without any recompile. To achieve this internally Qt's introspection-functionality like signals, slots, properties, enums, QVariant, QObject, QMetaObject, QMetaType, etc. are used to deal with functionality at runtime.

    What Kross is

    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.

    What Kross is not

    Kross does not implement its own scripting language, rather, it provides access to already existing solutions. Kross does not implement a complete Toolkit-binding, rather, it provides access to already existing solutions like PyQt/PyKDE or TkInter for Python or Korundum/QtRuby for Ruby. Kross does not auto-generate code, it is not needed to maintain any configuration files, and it does not come with yet another bindings-API. All it does is to connect things transparently together and to offer optional access to already existing technologies.

    Reuse and choice are the goals

    There exists a wide range of solutions to deal with scripting. Programming languages like Python have enjoyed years of evolution and a large community around them with 3rd-party modules for nearly everything. The same goes for a lot of other languages where there sometimes exists a special function that is only available to a particular language, and where each language comes with its own way of doing things. Each user may have their own preference for what scripting language they like to use, and over time, may have acquired skills in some specific areas.

    Rather than limiting users to only one specific language with its own way of doing things, Kross offers a flexible way of supporting multiple programming languages without additional code and maintenance work, at the application level. Kross allows the user to choose what they like and know the most, and it minimizes the entry-barrier to get his things done and to be able to contribute to one's own solutions significantly.

    Supported interpreters

    As of today Python, Ruby and JavaScript are supported. While all of them are passing the unittests, current state is, that Python is the most complete one followed by Ruby which is near the same state and finally JavaScript which needs some more tweaks to be as rock-stable as the other both implementations.

    Work on progress are krossjava (thanks to google for supporting this plugin within the Google Summer of Code 2007) that implements support for the Java Virtual Machine and krossfalcon that implements support for The Falcon Programming Language.

    For sure any interpreter-plugin you may like to implement is very welcome. At the end the open source world is about choices :)

    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.
    • 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 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 its 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.
    • A lot of documentation, scripts and applications are using Kross already today. The latter guarantees that Kross offers the solution for many scenarios.
    • 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.
    • 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 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. 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. Kross is part of kdelibs and thus follows strict policies to provide backward-compatibility at least during the lifetime of KDE4.

    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.

    Each interpreter plugin needs to implement two abstract classes;

    • The Kross::Interpreter class is a singleton controlled by the Kross::Manager and could be used to setup the interpreter or do other things to share functionality between instances of the Script class.
    • The Kross::Script class handles exactly one script instance. An application is able to deal with multiple scripts at the same time where each of them has its own instance of the Kross::Script class controlled by an instance of the more abstract Kross::Action class.

    Python

    The Python plugin implements access to the Python scripting language.

    The unittest.py Python script file implements unittests for common functionality. For the unittests kross does use a special test-application that got compiled if cmake -DKDE4_BUILD_TESTS=1 was used for kdelibs. You are able to run the unittest with

    cd kdelibs/kross/test
    ./krosstest unittest.py
    

    Other scripts are...

    • The testkross.py Python script file demonstrates how to use Kross to execute some JavaScript code within a python script.
    • The testguitk.py Python script file that creates and displays a modal dialog using the TkInter GUI-toolkit.
    • The testguiqt.py Python script file shows how to use PyQt while the testguiform.py uses the Kross Form module.

    The krosspython plugin consists of...

    • The Kross::PythonInterpreter class implements Kross::Interpreter for the Python interpreter backend and implements the createScript factory method to create Kross::PythonScript instances.
    • The Kross::PythonScript class implements Kross::Script for the Python backend to provide the functionality to execute Python code within a script-container.
    • The Kross::PythonModule class is the __main__ Python environment used as global object namespace. This module is shared between the different Kross::PythonScript instances which run in there own module namespace. The Kross::PythonModule also spends access to the the whole Kross functionality and manages all the @a Kross::PythonExtension modules.
    • The Kross::PythonExtension class implements a Py::Object to wrap a QObject instance into the world of Python.
    • Within Kross::PythonVariant the Kross::PythonType helper class is used to cast between QVariant and Py::Object values while the Kross::PythonMetaTypeFactory helper class is used as factory within Kross::PythonExtension to translate an argument into a Kross::MetaType needed for QGenericArgument's data pointer.

    Ruby

    The Ruby plugin implements access to the Ruby scripting language.

    The unittest.rb Ruby script file implements unittests for common functionality. For the unittests kross does use a special test-application that got compiled if cmake -DKDE4_BUILD_TESTS=1 was used for kdelibs. You are able to run the unittest with

    cd kdelibs/kross/test
    ./krosstest unittest.rb
    

    The krossruby plugin consists of...

    • The Kross::RubyInterpreter class implements Kross::Interpreter for the Ruby interpreter backend and provides with the createScript a factory method to create Kross::RubyScript instances.
    • The Kross::RubyScript class implements Kross::Script for the Ruby backend to provide the functionality to execute Ruby code within a script-container.
    • The Kross::RubyModule class is the __main__ Ruby environment used as global object namespace. This module is shared between the different Kross::RubyScript instances which run in there own module namespace. The Kross::RubyModule also spends access to the the whole Kross functionality and manages all the @a Kross::RubyExtension modules.
    • The Kross::RubyExtension class implements a Ruby VALUE object to wrap a QObject instance into the world of Ruby.
    • Within Kross::RubyVariant the Kross::RubyType helper class is used to cast between QVariant and Ruby VALUE values while the Kross::RubyMetaTypeFactory helper class is used as factory within Kross::RubyExtension to translate an argument into a Kross::MetaType needed for QGenericArgument's data pointer.

    JavaScript

    The KDE JavaScript plugin uses the in kdelibs4 included Kjs and KjsEmbed4 frameworks to provide access to the JavaScript language.

    The unittest.js KDE-JavaScript script file implements unittests for common functionality. For the unittests kross does use a special test-application that got compiled if cmake -DKDE4_BUILD_TESTS=1 was used for kdelibs. You are able to run the unittest with

    cd kdelibs/kross/test
    ./krosstest unittest.js
    

    For details about KDE-JavaScript see...

    Java

    The Google Summer of Code 2007 did provide us the krossjava backend for Java :-)

    Falcon

    The krossfalcon plugin does implement access to The Falcon Programming Language.

    The Module plugins

    Modules are plugins loaded on demand at runtime to provide additional functionality. They only provide a factory to create and return a QObject instance that is then exposed to the scripting backend.

    Since Qt's introspection functionality is used, we are able to throw in just QObject's and have them act as classes/objects within a scripting backend. Slots are membermethods while properties and enumerations are membervariables. If your application also likes to offer D-Bus support it may be an idea to reuse the QDBusAbstractAdaptor implementations your application has also for scripting, like for example KSpread did.

    Let's take a look at the following code that implements the MyObject class which inherits from QObject;

    class MyObject : public QObject {
      Q_OBJECT
      Q_PROPERTY(QString name READ name WRITE setName)
      public:
        MyObject(QObject* parent = 0) : QObject(parent) {}
        virtual ~MyObject() {}
        QString name() const { return objectName(); }
        void setName(const QString& name) {
          return setObjectName(name);
        }
      public slots:
        QObject* create(const QString& name,
                        QObject* parent=0) {
          MyObject* obj = new MyObject(parent);
          obj->setObjectName(name);
          return obj;
        }
        QObject* parent() const { return QObject::parent(); }
        void setParent(QObject* parent) {
          QObject::setParent(parent);
          emit parentChanged(); 
        }
      signals:
        void parentChanged();
    };
    
    extern "C" {
      KDE_EXPORT QObject* krossmodule() {
        return new MyObject();
      }
    }
    

    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.

    Then we just need to have our myobject.h and myobject.cpp files, filled with the content above, defined in the CMakeLists.txt file. The library needs to be named "krossmodule..." where the "..." is then the name the module is accessible as. For our example we use "krossmodulemyobjectmod" and therefore we are able to access the module if installed as "myobjectmod". The example does not depend on Kross, so you may like to replace ${KROSS_INCLUDES} with whatever else your module depends on.

    include_directories(${CMAKE_SOURCE_DIR}
      ${KROSS_INCLUDES})
    set(krossmodulemyobjectmod_PART_SRCS
      myobject.cpp)
    kde4_add_plugin(krossmodulemyobjectmod
      ${krossmodulemyobjectmod_PART_SRCS})
    target_link_libraries(krossmodulemyobjectmod
      ${KDE4_KDECORE_LIBS} ${KDE4_KROSSCORE_LIBS})
    install(TARGETS krossmodulemyobjectmod
      DESTINATION ${PLUGIN_INSTALL_DIR})
    

    The following Python sample code accesses then the module at runtime and uses the QObject, calls its 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");

    #!/usr/bin/env kross
    import Kross
    m = Kross.module("myobjectmod")
    m.name = "MyObjectModuleName"
    obj1 = m.create("OtherObjectName")
    def myCallbackFunc(args):
        print "The parent of obj1 changed"
    obj1.connect("parentChanged()",myCallbackFunc)
    obj1.setParent(m)
    print "%s %s" % (obj1.name,obj1.parent().name)
    

    Manager, GuiClient, Action

    The 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.

    #!/usr/bin/env kross
    import Kross
    a = Kross.action("MyKjsScript")
    a.setInterpreter("javascript")
    a.setCode("println(\"Hello world from Kjs\");")
    a.trigger()
    

    The 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.

    The 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 Kross::Interpreter instance created by 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.

    #!/usr/bin/env kross
    import Kross
    print "objectName=%s" % Kross.objectName()
    print "interpreters=%s" % Kross.interpreters()
    print "objectName=%s" % self.objectName()
    print "text=%s" % self.text
    print "enabled=%s" % self.enabled
    print "currentPath=%s" % self.currentPath()
    print "interpreter=%s" % self.interpreter()
    print "description=%s" % self.description()
    print "code=%s" % self.code()
    

    D-Bus and Kross

    With the QtDBus module Qt provides a library that a Qt/KDE application is able to use to make Inter-Process Communication using the D-BUS protocol.

    The QtDBus module uses the Qt Signals and Slots mechanism. Applications that like to provide parts of their functionality to the D-Bus world are able to do so by implementing classes that inherit from the QDBusAbstractAdaptor class.

    Kross is able to reuse such by an application provided bindings. So, once your application supports D-Bus, Kross is able to reuse those already existing code and offers transparent access to the scripting-backends to them. How does this differ from e.g. the python-dbus package? Well, first method-calls don't go through the dbus-socket and then it's not dbus-related at all except, that we are able to reuse what your application offers anyway: a clean interface to the outside world. But that's not all, we are not limited to what's possible with D-Bus. We are also able to exchange instance-pointers to QObject or QWidget instances.

    For an example you may like to take a look at how it was done in the Calligra Sheets ScriptingModule class.