[Fwd: kwrite]

[Christian Couder]

Simon Hausmann wrote:

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

Thanks for your support.


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

Yes.

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

Ok, that's fine for me.

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

I commited the Comment/Uncomment stuff, so now I am going to see if this would
break a lot of things.
I hope to tell you soon if some work should be done before you can setup the
link.

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

As far as I am concerned, I 'd prefer for sure to use the generic editor
interface.

Bye,
Christian.