KDevelop editor interfaces

[Cullmann Christoph]

Am Sonntag, 22. April 2001 15:54 schrieb Matthias Hoelzer-Kluepfel:
> Hi all,
>
> for the last couple of days, I have been thinking about how to
> improve the editor interface used in KDevelop. The main reason
> was that I love writing kdevelop parts, but while writing the
> konsole and the astyle part, I noticed that even for simple
> tasks, a part has to 'talk' to the editor. And currently, this
> means to refer to a lot of internals of the specific editor
> implementation used by kdevelop.
>
> Unfortunately, a simple generic interface like KTextEditor
> seems not enough for the tight integration you need inside
> KDevelop. I talked to some people about that problem (Simon
> Hausmann and Cornelius Schumacher, to be precise), and we
> discussed several proposals how to find a usefull, but still
> managable interface.
>
> There are two main challenges in designing this interfaces:
>
> a) It should be easy to make an editor implement the interface
> b) It should be easy to use an editor based on the interface
>
> Of course, Simon and Cornelius found a nice solution that was
> much better than my proposals, so I trashed mine and adopted
> theirs :-)
>
> The solution we came up with is that we need a modular
> interface that is extensible. This means that an actual
> implementation of an editor implements a basic interface
> as well as an arbitrary number of additional interfaces with
> advanced functions. Of course, not every implementation would
> have to support all interfaces.
>
> The user of the interface would then be able to use the basic
> interface to query for the advanced interfaces the
> implementation supports, and can act accordingly. For example,
> a kwrite/kate based implementation might offer the
> "BreakpointInterface", while a kfte based implementation might
> not. This would mean that using kfte, you would loose the
> possibility to set a breakpoint right in the editor, but you
> could still use all the other functions provided by kfte.
>
> Ok, that's the theory. In practice, it is quite hard to find
> the right interfaces, and so I just started with the most
> basic ones. I defined a small set of them, wrote a very simple
> implementation (usigin qmultilineedits :), a test program and
> even started to hack support into kdevelop. It is not more
> than a proof-of-concept, but it is ok for a start.
>
> Before I go on, I would like to discuss these ideas with
> everyone interested. I will commit the code I already have
> (without the integration into KDevelop, to not break anything)
> soon. If you think that is a sensible way to go on, I would
> then try to port the kwrite used in kdevelop to the new
> interface and switch to the new interface internally. If you
> don't like it, well, then we have to make it better :)
>
>
> Comments?

I could have a solution for all those problems.
Kate has a abstract interface for its editor part (doc-view-model, like 
ktexteditor). These interfaces are kate independent (don't link to any kate 
stuff). At the moment the interface headers are under kdebase/kate/interfaces 
(only view.h and document.h are interesting for the editorpart stuff) and the 
lib in which the interfaces live is libkate.sa.
The interface headers are installed by kdebase/kate under $(includedir)/kate 
and I have created a servicetype Kate/Document to load them.
KDevelop can for example use libkatecore.so (the kate lib which implements 
the abstract interfaces from libkate.so) and load it via klibloader + 
kfactory to create the documents which can create the views (Kate::View 
public KTextEditor::View, Kate::Document public KTextEditor::Document)

Later the kate interfaces could be used by any other app like kfte/kvim/.... 
after someone helped me to implement all needed functions as virtual 
functions to the interfaces kdevelop needs.

4 good things with this solution:
1. KDevelop isn't Kate depended if some other devs write kfte/kvim parts 
which implement the classes Kate::View and Kate::Document which are located 
in libkate.so.
2, From beginning on you can use the katepart and can drop your old kwrite 
stuff.
3. I will help to do that ;)
4. with the Kate/Document servicetype kdevelop can build up a editorpart 
browser and the user can select the editorpart he wants and which is 
installed on the system. (k, at the beginning only katepart supports 
Kate/Document, but that can change if some guy do the stuff in kfte...)


cu
Christoph



>
> Bye,
> Matthias.

-- 

| |   / /               - get an edge in editing -
| | / /                      »»»» GET KATE ««««
| |/ /      a fast and capable multiple document,
|     \     multiple view text editor for KDE
| |\  \     cullmann at kde.org
| |  \  \   http://devel-home.kde.org/~kate

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