[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: kwrite
From:       Simon Hausmann <shaus () helios ! Med ! Uni-Magdeburg ! DE>
Date:       2000-05-24 10:47:24
[Download RAW message or body]



On Wed, 24 May 2000, Christian Couder wrote:

> Hi,
> 
> I am a kdevelop developer and a few days ago I subscribed to this list and I
> started porting some improvements to kwrite.
> These improvements (mainly some breakpoint and bookmark code and
> comment/uncomment commands) were made on the kwrite code in kdevelop.

Great!

> Simon Hausmann wrote:
> 
> > [...]
> > The gives us the following advantages:
> >
> > - The kwrite hackers will be able to hack, improve and extend kwrite
> >   without having to worry about binary or source incompatibility
> >
> > - We have a generic texteditor interface plus a working implementation,
> >   bringing us one step nearer to the dream of apps like kdevelop giving
> >   the user the choice to choose his/her favourite text editor for
> >   programming in kdevelop
> 
> I am sorry but I don't know much about kparts and I also don't know how the
> kwrite development/partifying has gone so far so I have to ask a few
> questions:
> 
> What are the next steps to make this dream a reality?

The first step is comitting :) I'll see if I can commit either today or
tomorrow.

What's left then is:
- finish the action'ification of kwrite (use the action concept and split
  up between shell and document/view actions)
- finish up the KTextEditor interfaces
  (including access to text attributes, etc., so that for example kdevelop
   can highlight text of a breakpoint for the debugger)
- port kdevelop to use the KTextEditor interfaces and (most important)
  make KDevelop use the xmlgui framework.
  (these are two points I probably won't be able to help with)

> Who is also working on this on the kwrite side?

Jochen Wilhemly, as kwrite Author :-)

I won't be able to work much on the follow up work. My goal was to solve
the API/binary-compatibility problem of kwrite (as it is in kdelibs, and
kdelibs will be frozen for binary incompatible changes for at least one
year (beginning the with KDE 2.0 release) and to provide a skeleton for a
generic texteditor interface.

> And when do you think kwrite will be ready to be included in kdevelop as a
> kpart?

I think that mostly depends on when kdevelop will be ready :) . I'm sure
that kwrite will be ready first ;-)
(at least for general usage and with a stable API (which is most
important))


Bye,
 Simon

[prev in list] [next in list] [prev in thread] [next in thread]