A final word (was:Re: What's up and what's hot)

Matthias Hoelzer-Kluepfel mhk at caldera.de
Mon Aug 13 14:05:43 UTC 2001

On Mon, 13 Aug 2001, F at lk Brettschneider wrote:

> Could you give us a survey about the editor architecture you created?
> What I want to have is a something like a class diagram or an entity
> relationship model of the current program, just only the part
> editor/doc-view-management/GUI-interface, you know what I mean.
> And maybe some lines of description as far as it is necessary for
> understanding.


I think it is easier to describe than to draw a diagram :-)

One important point is that the editor interfaces don't deal with doc/view
management at all, nor should they. This is the task of the doc/view
manager (which, currently, is almost not existant :)

What this interfaces try to achieve is to abstract the functionality of
an editor.

The basic starting point is the KEditor::Editor interface. This is the
entry point to an actual implementation. At runtime, I look up which part
to load to get a KEditor::Editor, e.g. the Kate part.

Once I have a KEditor::Editor, I can use functions like createDocument to
get a new document, or get a pointer to an existing one. The documents are
of type KEditor::Document, and provide only basic functionality like load
and save. If fact, the documents are KParts::ReadWriteParts.

They documents have one more interesting function, and that is
queryInterface. With this function, I can ask the document if it provides
a certain additional interface. So the debugger part will query for the
DebugInterface, which, if present, will allow to set breakpoints in the
editor window. If the interface is not present, the debugger will have to
rely on the breakpoint window only.

So the advantage is twofold:

a) I can use different editor implementations, some providing the
   DebugInterface, some not.
b) The debugger part needs to know only the DebugInterface, so it this
   doesn't change, the debugger part does not need to be changed (or even

Of course, there is quite a number of additional interfaces, and we can
add as many as we think we need.

Here is a short example how to use the framework:

// this will get the current document in the editor
KEditor::Document *doc = core()->editor()->currentDocument();
if (!doc) return;

// this will get the basic editing interface
KEditor::EditDocumentIface *iface =
if (!iface) return;

// this will insert some text
iface->insertText("Hello World");

Note that the KEditor::EditDocumentIface::interface function is just a
convenience function around queryInterface

I hope this makes things clearer.


to unsubscribe from this list send an email to kdevelop-devel-request at kdevelop.org with the following body:
unsubscribe »your-email-address«

More information about the KDevelop-devel mailing list