kwrite

[Christian Couder]

Hi everyone,

"W. Tasin" wrote:

> Falk Brettschneider wrote:
> >
> > Hi,
> >
> > What was the latest news about kwrite?
> > To change things we've got only time until next Wednesday when the total
> > KDE interface freeze will begin.

We won't have enought time.

First because we cannot change kdevelop to use a kwrite part in so few days.
And it would be very difficult to build the kwrite part interface without
testing it.

It would be also very difficult to build the kwrite part interface without a
finished kwrite.
And currently there are some things that should be finished in kwrite before
the interface can be completed.
These things are mainly the left border/bookmark/breakpoint stuff. I will
start to work on these things very soon because I nearly finished the
Comment/Uncomment stuff.

> I also think that we need an extra kwrite... there are too much things
> we need additionally to it (which isn´t already done and won´t be done
> just in time, like a interface to it for internal debugging and maybe an
> interface method which allows to get the changings made from a certain
> time stamp - for correcting breakpoints or for doing a kind of
> incremental parsing)...
> These are all things, which aren´t of interest in a base kwrite class.

These things aren't of interest in kwrite as a base class, but they are of
interest in kwrite if the kpart kwrite interface can use them.
That 's what we should do and that's what we planned to do, but it was too
late.

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.

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

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

Bye,
Christian.