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

List:       kde-core-devel
Subject:    Re: Code duplication in KWrite, comment/uncomment stuff
From:       David Faure <david () mandrakesoft ! com>
Date:       2000-05-28 21:04:02
[Download RAW message or body]

On Sun, May 28, 2000 at 10:55:59PM +0200, Falk Brettschneider wrote:
> Hi,
> 
> Simon Hausmann wrote:
> 
> > > > We make kwrite a separate CVS module and "link" it into the kdebase and
> > > > the kdevelop CVS module via CVSROOT/modules , just like kde-common/admin .
> 
> I don't understand that. Could you please explain why kwrite must be an extra cvs
> module to be able to be shared by several applications, especially KDevelop?
As you said, so that it can be shared by several other CVS modules,
without bloating kdelibs.
Note that with a CVS link it will transparent and will appear as a subdir
of the kdevelop module - I fail to see why you have a problem with that.

> KDevelop just want to have the opportunity to configure kwrite to its needs, that
> means:
> - redefine key-bindings,
> - emulate vi or emacs (maybe their behaviour, as well (like search strings)),
> - add features (breakpoints, comment/uncomment, bookmarks)
> - own context menus
> Give those ones the reason to remove kwrite from kdelibs?

I thought the idea was that some people preferred to use other text editors,
e.g. kvim, in kdevelop ? Hence the idea of the generic interface and multiple
implementations of it.

You mention above "make kwrite emulate vi" - this would be another way to
do it, but I think it's not the way the kvim developers have chosen.

Good I didn't do anything yet - let's agree on what to do first...

-- 
David FAURE, david@mandrakesoft.com, faure@kde.org
http://home.clara.net/faure/
KDE, Making The Future of Computing Available Today
See http://www.kde.org/kde1-and-kde2.html for how to set up KDE 2

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