The examples shown here are cut from pages in the PyKDE4 class reference. The first is a typical header for a class page - shown compressed horizontally.

The features are fairly obvious. The class name is at the top left. Below it, the contents of the box indicate the module the class is found in, the namespace it belongs (global is effectively "none"), and the base class (if any) the class is derived from.

The links in the upper right hand corner link to the table of contents, a module page which lists all of the modules (with links to their classes), a link to the kdeui module page, and link to a list of all PyKDE4 classes.

Below the links is a description of the class - these may be short, extremely lengthy or may include usage examples of the class or its methods.

The methods section of class's page lists in alphabetical order all of the methods defined in the KDE4 class declaration. If the class has base classes, there are probably considerably more methods inherited from the base class which are not shown here.

The left-hand side of the page lists the methods and their Python signature. The argument list shows the names and numbers of the arguments, but not their types. The type information is listed in a table below the method name. Each row shows the argument name, its type, and the default value, if any. Methods which are not implemented in PyKDE4 are labeled and will have their method name "grayed out".

Above the table the type of value returned by the method (if any) is described.

On the right-hand side is description (again, some short, some lengthy) that describes what actions the method performs. Some methods (or even entire classes) are marked as Internal, Deprecated, or Obsolete. These determinations are made by KDE4 programmers. Methods and classes like those are included in PyKDE4 for completeness or because in some cases, other methods or classes depend on the marked method or class.

You should avoid using internal, deprecated or obsolete methods in your code, as their function may change or they may disappear in new releases.

Versions If there are no version limitations specified, the method is available in all PyKDE4 versions. Versions are specified as "KDE X.Y.Z and later", which means the method is available in version X.Y.Z, as 'before KDE X.Y.Z", which means the method is NOT available in version X.Y.Z, but is available in any previous version, or "KDE A.B.C to before KDE X.Y.Z", which means it is available in version A.B.C, any version before X.Y.Z, but NOT in X.Y.Z itself. Or in other words, versions are always given as A.B.C <= version < X.Y.Z

If a class defines enums, the enum and its enumerators are shown at the top of the page.

Sometimes it's clear from the names of the enum and enumerators what they represent. For some enums, more detailed explanations have been provided, and these are attached at the bottom of the page (accessible by clicking the "enum details" link)

If more descriptive detail is available, its shown at the bottom of the page in the "enum details" section.

In the case shown, the programmer has provided a brief description of the function of each enumerator.

This clipping shows two different types of methods - signals and static methods.

A static method (at the top) is one that can be called without creating and instance of the class it belongs to - simply call className.methodName () to use the method.

A signal is emitted when some particular action has occurred (a button clicked, a page has completed printing or rendering, etc). Signals are connected to slots.

Besides labeling this method as a signal, the documentation shows the signal's "signature" and a SIGNAL statement, which can be pasted into a 'connect' call that links the signal to a slot that responds to the occurance the signal represents.

The final examples show how abstract classes and pure virutal methods are identified.

Abstract classes are classes that can be used as a base class for new classes, but can't be instantiated themselves. The label under the class name defines this class as abstract.

A class is abstract when it has pure virtual methods. If a class is to be derived from an abstract class, the pure virtual methods (which are empty) must be replaced by usable methods in the new (derived) class.

The methods in the new class must have exactly the same number and types of arguments as found in the pure virtual method's declaration.