[Fwd: kwrite]

[Simon Hausmann]

On Sun, 4 Jun 2000, Christian Couder wrote:

>I think, what would be best is to ask for more time to do all this.
>For example they could freeze everything except the kwrite/ktexteditor stuff,
>because this is not really core stuff.

Yes, I think that's the best solution.

Kurt, would it be possible to treat kdelibs/interface/ktexteditor.* as
exception?

Hacking this interface and breaking BC for KTextEditor:* would only affect
kdebase/kwrite, and I think it would be really cool if the kdevelop
hackers would manage to hack up the interface to their needs, while still
keeping it as abstract interface in kdelibs, so that it will be possible
for the kvim hackers to implement the interface, too -> Giving the user
the choice of his favourite editor in kdevelop. (and in Kafka, too, btw)

>There is also a where-do-we-put-the-kwrite-stuff problem.
>The texteditor part stuff must be in kdelibs, but the kwrite stuff could be
>in kdelibs too or in kdebase.
>It's probably easier for development if it's in the kdelibs and it also make
>kdevelop depends on kdelibs only.
>But kwrite itself is not a library and a kdelibs freeze was planned sooner
>than a kdebase freeze so the kwrite stuff was removed from kdelibs and put in
>kdebase.
>
>My opinion is that the kwrite code the texteditor part depends on should be
>in the kdelibs because it is used as a library by kdevelop and perhaps will
>be used as a library by other stuff too. This part of the kdelibs could be
>freezed latter. The other kwrite stuff could be elsewhere (kdebase or
>kdeutils).

The reason why kwrite (not the texteditor interface) was moved to kdebase
was because kwrite is an application, while kdelibs is meant to contain
core libraries.

We agreed with Ralf Nolden that we make this kind of CVS-link in
kdevelop/kwrite, linked from kdebase/kwrite . That means kdevelop/kwrite
will always automatically contain an exact copy of kdebase/kwrite, while
not having the dependency of kdevelop depending on kdebase.

I think we can setup this link as soon as the kdevelop developers are
ready :-)

>> I think a better compromise would be to create a xkwrite class derived
>> by the actual kwrite class (hoping that this would be possible ;-)).
>
>The goal is to use kparts as much as possible, and it seems that
>unfortunately the code in kparts we use cannot be inherited from.

Right. It does not make sense to want to inherit from a base class if at
the same time you want to have the capability of dynamically loading the
editing component, with the goal of letting the user choose his favourite
editor.

Well, the decision is up to you :-) . Either you decide to use and depend
on kwrite directly or add the necessary functionality into the generic
editor interface and loading the editor component from a shared library at
run-time.

Bye,
 Simon