Don Sanders sanders at kde.org
Mon Oct 7 13:53:48 BST 2002

On Monday 07 October 2002 13:58, Zack Rusin wrote:
> Hi everyone,
> I'm moving our discussion to kde-core-devel.
> To get everyone up to speed, the idea is pretty simple - our
> KTextEditor interfaces are too primitive to produce a robust text
> editor. To be more exact we were working on getting KTextEditor
> working in KMail for 3.2 but the thing is that KTextEditor wouldn't
> provide many things we want, like : coloring quoted text like we do
> in the readerwindow, incremental spell-checking (underlining over
> misspelled words) - more-less all rich text editing capabilities.
> So we're left with two choices :
> a) work with another text editor (KRichTextEditor or KoText),
> b) work on fixing KTextEditor and then porting KRichTextEditor or
> KoText derivative to the new interface,

I think b) sounds best. But I would 'fix' the KTextEditor interface by 
creating a KMEditor interface working on that in kmail/make_it_cool, 
and create bindings for the KMEditor interface for each supported 
text editing component (kate, krichtext, kotext and kedit). Later if 
KTextEditor covers all of the KM editors needs then the obsolete 
bindings can be removed as support for the KTextEditor interface is 
implement for the various text editing components.

I think this solution prevents the libs freeze from retarding 
progress. Prevents the need for a new kdelibs make_it_cool branch and 
having KM dependent on that. Allows the text editing interface 
changes to be kept private until the are ready for inclusion in 
kdelibs, and allows the widest range of text editing components to be 
supported with the least amount of effort.

This is the way optional addressbook support was implemented in KMail 
for a time, and it allowed experimentation for a duration until only 
one addressbook was remaining (due to attrition and merging). 

I do suggest supporting the current KEdit implementation (by creating 
a KMTextEditor Interface implementation for KEdit) until any quirks 
in the other text components are worked out.

When a non KEdit text component becomes better suited for KM 
composition then it can be made the default.


More information about the kde-core-devel mailing list