There are scripting oriented subclasses of Tutorial and Step classes, which are used in scripts instead of their standard superclasses.

The ScriptedStep class makes possible to execute functions defined in the script when the step starts or ends, or when a condition of a WaitFor or Option is met, instead of calling an overriden method or a slot respectively like its normal counterpart does. This is needed because there is no way to define methods that are part of a C++ class in the scripts, just plain functions.

The ScriptedTutorial class also supports calling a function when it is started or ended. But it does something a lot more important: it reads the script file and executes it, thus building itself with the steps defined in the script.

Another drawback of scripts is that using just Kross (that is, without language bindings), objects of C++ classes can't be created. Thus, a way to create steps, options and waitfors is needed.

ScriptingModule takes care of that, acting as a factory for those classes. As KTutorial supports custom WaitFor objects, ScriptingModule also supports (thanks to Qt Meta-Object System) creating objects of custom C++ WaitFor subclasses in the scripts just registering these classes (provided they have a default constructor).

Unlike C++ tutorials which are part of the code of the application, scripted tutorials, by its very nature, are external elements. They are like any other data: icons, sounds, images... That is, they have to be placed somewhere to be found.

ScriptManager class takes care of looking for the tutorials in their standard locations and creating a ScriptedTutorial for each of them. If the tutorial was successfully created, it also registers it automatically in the general tutorial manager, as it was already said.

Here it is the final diagram for scripting design, that includes all the explained elements and shows (if size doesn't prevent it) the relations between each of them: