KTextEditor

[Don Sanders]

On Monday 07 October 2002 20:22, David Faure wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Monday 07 October 2002 12:03, Don Sanders wrote:
> > On Monday 07 October 2002 17:52, David Faure wrote:
> > > Not necessarily. You could embed a component (dlopened), that
> > > provides this functionality.
> >
> > But that's still a runtime dependency. I'm concerned that
> > requiring people to install koffice in order to use KMail is too
> > big a dependency. Not so much for the typical end user but rather
> > for contributors who build from cvs.
>
> No, it's not a strict runtime dependency, if you have other
> implementations of KTextEditor, like kate. The idea would be:
> * If you want plain text editing in KMail (like right now), you
> only need kdebase (or even kdelibs if there's a ktexteditor
> implementation there, I don't know the current status). * If you
> want richtext editing in KMail, then you need koffice. It's a
> "weak" dependency. KMail runs without it, but if you want the extra
> feature, then you need koffice.
> Ok, now the choice is yours, but I wanted to make this clear.

Yes, I agree it's not necessarily a strict runtime dependency. But it 
could well be a 'in order for KM to work best you need KWord 
installed' dependency. 

I have limited reservations about that, it's possible (likely IMO) 
that there will be glitches when koText is embedded in the KM 
composer, and hence a desire to change koText so that it better meets 
the needs of KM. There's a social aspect involved with the KM 
developers becoming dependent on the KWord developers.

The same thing applies to kate. IIRC one week ago Kate didn't support 
paragraph based word wrap and I find this a severe limitation. Since 
then to my astonishment paragraph based word wrap has been 
implemented in Kate. But I still feel Kate needs a modification 
before it is suitable to replace the current KMail editing widget. 
Specifically support for character based word wrap rather than widget 
width wordwrap.

Of course there's also the issue of having KWord support the 
KTextEditor interface. The KTextEditor interface looks big, does it 
really make sense to have KWord support it all, or does it make more 
sense for some KSimpleTextEditor subset to be implemented?

...
> Problem is, you can't use QTextParag. It's a private Qt class.

True, I forgot this, good point.

...
> Anyway, as I stated above, I think it would be better to have
> "background spell checking" functionality independently from
> KTextEditor, so this problem doesn't happen.

Yeah, I'm convinced solution two is not worth pursuing.

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

Another option is to have a new KM editor interface and requiring an 
implementation of that for each text editing component that is 
supported by the KM composer. That way we can get support for 
KRichTextEditor and koText without requiring either one to support 
the KTextEditor inteface. The downside being custom code is needed 
for every text editing component supported by the KM Composer. 

However that custom code can be eliminated if or when components 
implement support for the KTextEditor interface.

Don.

NB: I using KM to refer to the KDE Mailclient I work on, whatever that 
may end up being named.