From kdevelop-devel Mon Aug 13 14:05:43 2001 From: Matthias Hoelzer-Kluepfel Date: Mon, 13 Aug 2001 14:05:43 +0000 To: kdevelop-devel Subject: Re: A final word (was:Re: What's up and what's hot) X-MARC-Message: https://marc.info/?l=kdevelop-devel&m=99771169925773 On Mon, 13 Aug 2001, F@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. Falk, 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 recompiled). 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 = KEditor::EditDocumentIface::interface(doc); 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. Bye, Matthias. - to unsubscribe from this list send an email to kdevelop-devel-request@kdevelop.org with the following body: unsubscribe »your-email-address«