Kross (software) explained
| KDE Frameworks |
| Kross |
| Developer: | KDE |
| Programming Language: | C++ |
| License: | LGPL |
See main article: KDE Frameworks. Kross is a scripting framework for KDE Frameworks. Originally Kross was designed for use in KOffice but eventually became the official scripting framework in KDE Software Compilation 4. Kross is designed to provide full scripting power for users of KDE applications, with a language of their own choice; and make it easy for developers targeting the KDE platform to enable their application with support for multiple scripting languages (without themselves needing to be proficient in any of them).
The Kross scripting framework is not a scripting language itself. It merely serves to plug into KDE the support for other, already existing scripting languages. Currently supported are: Python, Ruby, and JavaScript and the Falcon Programming Language. Addition of other scripting languages is made easy by the modular architecture of the framework.
Kross provides the following advantages over other approaches to enable scripting for desktop applications or desktop environments:
- The user is free to pick and use their favorite language for the scripting efforts
- The application developer does not need to know the specifics about a scripting language
- Other scripting languages can be easily added by writing a module/plugin for Kross.
Comparison with other scripting frameworks
SWIG: Simplified Wrapper and Interface Generator
- Kross currently has fewer supported scripting languages.
- Kross is built on top of Qt/KDE. This allows access to Qt/KDE things without needing extra effort to wrap them.[1]
- Applications supporting Kross do not require as much code as to support SWIG.[1]
- With SWIG, the set of supported scripting languages is determined at the time of compiling the application: each supported language must either have code in the application to invoke that language's interpreter, and/or have a shared library specific to that application–language pair whereas Kross doesn't need to know until runtime.
AppleScript
Compared to AppleScript's Open Scripting Architecture (OSA):
- OSA can be used with IPC (Apple events), allowing a script to be in a separate process, whereas Kross scripts always run in the same process as the main application. In practical terms, using IPC allows a script to interface between several already-running applications; Kross does not.
(IPC is not technically necessary for one script to access code from many applications at once: a script can link against library forms of those applications, such as the libraries produced by SWIG.)
- While Kross allows the scripter to write scripts in a language of their choice, AppleScript is one given language, though it can be called from within other (scripting) languages.
- Kross always requires code added to the application explicitly for Kross, whereas many macOS applications have basic scriptability just because of their choice of GUI toolkit (Cocoa) (see AppleScript in macOS). (Dogtail and other GUI testing/automation tools also have this property.) “Basic scriptability” here means at least being able to click on buttons and menus and access information provided to accessibility software such as Screen readers.
Kross does not currently have any provision for running untrusted scripts, i.e. does not allow restricting what scripts can do. Kross developer Sauer[2] suggests either using a language with good sandbox support (such as by using the experimental Java plugin) or using approaches to increase the trust in scripts, such as using signed scripts.[3]
Applications using Kross
External links
Notes and References
- Web site: ? . 2007-05-16 . https://web.archive.org/web/20060924165701/http://www.kexi-project.org/wiki/wikiview/index.php?Scripting . September 24, 2006 . dead .
- http://dot.kde.org/1168284615/ The Road to KDE 4: New KOffice Technologies
- Web site: ? . dead . https://web.archive.org/web/20060924165701/http://www.kexi-project.org/wiki/wikiview/index.php?Scripting . September 24, 2006 .
