Tutorial classes

The core classes of KTutorial are, obviously, those related to the implementation of tutorials. This module contains all the classes needed for that task.

Tutorials are just a succession of steps to be given by the user to accomplish some task. In each step, some text tells the user what must be done. Once the user does it (that is, some conditions are met), a next step is activated. Also, steps can show some options to be choosen from by the user.

Now it will be explained in higher detail how that is designed.

To model the conditions to be waited for, a Composite design pattern is used. There is an abstract base class which represent conditions to wait for. WaitFor objects can be active or not, and they emit a signal when their condition is met. Whether the condition was met or not depends on how subclasses implement that method.

The most simple child of WaitFor is WaitForSignal. As its name suggest, it waits until some signal is emitted. In that moment, its condition is met and its wait ends, emitting a signal.

Another simple child is WaitForEvent, that waits until an event of some specific type is received in an object.

In most cases, waiting for a signal or event is the only condition to be met. However, in some cases it may be needed to met composed conditions. These can be "and" or "or" boolean conditions checked against the children of a composed condition.

There is also a special condition, WaitForNot, that should be used in composed conditions to check if its internal condition wasn't met yet.

Each Tutorial is composed of several steps. Each Step contains some text to be shown to the user explaining what must be done, and zero or more conditions to wait for or options. Only the currently active step waits for conditions. That is, if the condition of some step is met when that step isn't the one being shown to the user, the condition is ignored and still not met.

A Step connects conditions to wait for with slots to be called when the condition is met (for example, to change to another step). In a similar way, it also connects options and the slots to be called when the user selects the Option.

In this simple scheme resides the essence of KTutorial: waiting for conditions makes possible to wait for the user to accomplish some task and advance to the next step in the tutorial when that task is done.

As changing to the next step is the usual response when a condition is met or an option selected, the Step class provides a shortcut to change to another step without needing to use a specific slot just for that.

When a Tutorial is being executed, there is only one Step active at a time. Activating one step automatically deactivates the previous one.

To activate a step, it must be set as the next one in the tutorial. The tutorial advances by progressively setting the next step once the conditions in each current step are met.

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