What Kross is
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.
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.
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.
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.
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 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!
- 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.
- 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 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 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.
- 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.
- 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.
- 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.
- 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.
- 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.