KDevelop editor interfaces

Matthias Hoelzer-Kluepfel mhk at caldera.de
Sun Apr 22 15:29:54 UTC 2001


On Sun, 22 Apr 2001, Cullmann Christoph wrote:

> 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.

Hi Christoph,

I had a look at these interfaces, and I fear that if we use
these, we end up in the same situation we are now wrt the
kwrite interfaces we are using.

I think that the kdevelop<->editor interface should be a bit
more generic. Nevertheless it should be very easy to make a
kate plugin for kdevelop, given the clean separation you
already have with that interfaces. (In fact, as I look at them
again, perhaps I shouldn't even bother to port the kwrite
code, but to write a kate plugin instead ;)


> 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.

Here is where the problems start: if you go down that road,
you will end up with adding function after function to your
interface. And then you will notice that not all
implementations provide an equivalent functionality. And when
you are done adding everything kdevelop needs, someone will
ask you to add everything application xz needs...

I think having a modular interface is much easier in that
context.

Hm, I think I really should start to commit that code, instead
of just talking. Unfortunately I will be off the net later
today, so I would rather wait until tomorrow.


> 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.

Ok, that is true for whatever interface we decide on using.

> 2, From beginning on you can use the katepart and can drop your old kwrite 
> stuff.
> 3. I will help to do that ;)

These are good arguments :)


> 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...)

Again, this is not a unique feature of the kate interfaces.
And having a modular interface makes it much easier to
implement something for kfte than to implement all the
functions appropriate for kate.

Ok, I guess the discussion will be easier tomorrow, when I
have something more to show :)

See you then,
Matthias.



-
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