Joseph Wenninger jowenn at kde.org
Mon Oct 7 21:26:20 BST 2002


This mail contains a lot of different responses, opinions to the 
ktexteditor thread.

Don Sanders wrote:

>I'm not just limiting my thinking to those two solutions however. FWIW 
>I'm leaning towards the position that requiring a text editing 
>component to support the KTextEditor interface in order for that 
>component to be used in the KM composer is too strenous a condiiton. 
>(Does the vim part support the KTextEditor interface?)

The last time I looked the vimpart supports the KTextEditor interface, 
and I made it possible in the kwrite"shell" to embedd that part

The katepart has never been ment as an all in one solutions, 
(reverse_i18n("Eierlegendewollmilchsau");) which does everything 
somehow, but nothing right. It's main purpose has been and still is, to 
supply a text editing component suitable for source code editing and a 
way to even few really large files with an acceptable speed.

The problem you will always have with interfaces is, that not all 
implementors can or want to implement everything provided by an 
interface, you will always have to support workarounds, if you are 
trying to use user configurable plugins, because not all features have 
to be available. (You can easily check if a feature is available with 
qt_cast and inherits. dynamic_cast is not that a good solution, if you 
work with dlopened libraries).

The KTextEditor interface is open for any further abstract interface 
class (at least after KDE 3.1), if you think you need special features, 
just add an interface and hope someone implements it, but be sure to 
keep something in your app to work around an not implemented feature in 
an component.

I think the best way to implement spell checking is within the 
components, not outside, because it needs to know a lot about the 
internals (eg vimpart, kate, .....). The interface should only have a 
method for enabling/disabling it.

Kind regards
Joseph Wenninger

More information about the kde-core-devel mailing list