KTextEditor

Coding Guidelines and API Conventions

Overview | Design | Coding Guidelines | Porting to KDE Frameworks 5

All KTextEditor interfaces have a consistent design.

  • naming follows Qt style. Avoid Java style getters like getSomeData() for example,
  • core interfaces (see Overview of the Core Interface Design) which inherit QObject declare all signals as real signals,
  • all other interfaces, which do not subclass QObject, must declare their signals as virtual private member functions. An implementation must reimplement this virtual member function as a real signal.
  • all signals have the sender object as first parameter, for example all document signals have to look like this:
    void signalFromDocument (KTextEditor::Document *doc, ...);
    A KParts derived class representing a text document.
    Definition document.h:284
    This allows easy and consistent query which object did send the signal, which is important for most applications, as they listen to multiple documents/views/editors/...
  • all interface functions should be virtual, to allow subclasses to overwrite them, most members should even be pure virtual, beside additional convenience/helper functions.

The interface KTextEditor::Cursor represents a cursor position, i.e. a line/column tuple. The same holds for KTextEditor::Range. As both of this concepts are much cleaner than tuples, please keep the following guidelines:

Author
Christoph Cullmann <cullm.nosp@m.ann@.nosp@m.kde.o.nosp@m.rg>
Dominik Haumann <dhaum.nosp@m.ann@.nosp@m.kde.o.nosp@m.rg>
This file is part of the KDE documentation.
Documentation copyright © 1996-2024 The KDE developers.
Generated on Tue Mar 26 2024 11:15:44 by doxygen 1.10.0 written by Dimitri van Heesch, © 1997-2006

KDE's Doxygen guidelines are available online.