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

List:       kde-core-devel
Subject:    Re: Can we drop KWrite ?
From:       "Aaron J. Seigo" <aseigo () mountlinux ! com>
Date:       2001-03-13 22:43:43
[Download RAW message or body]

Hi...

> You missed my point. What's so great about having two text editors at the
> kedit/kwrite level, both of which must be maintained (one in the heart of
> kde, one in kdeutils)? I don't think that kwrite (or kant, for that matter)
> are beyond the ken of Joe-Wordpad user to master.

because kedit and kwrite are not at the same level =) 

for instance, pressing the Home key in kedit returns you to the start of the 
line; kwrite returns you to the start of the text of the line (and pressing 
it again returns you to the start of the line like in kedit). in kedit, 
clicking past the last  character in a line puts the cursor just past the 
last character in the line. in kwrite, it puts it right where you click.

you see, kedit is for simple text editing. for when you want a nice simple 
text file for which a word processor is vast overkill.

kwrite is slanted towards writing code. it has syntax highlighting, control 
over what a "tab" means, advanced cursor navigation, etc..

they are similar, but _not_ the same. both serve very different purpose IMO.

now, as for kant. i like the idea of the "light" IDE (it even has a compile option in one of 
the menus!) however the GUI has several (for me) huge usability issues, the 
largest of which is the forced-MDI style which, as i've been using kant to 
acclimatize myself to it, is proving more often annoying than not for the 
sort of things i used to use kwrite for. these are the sorts of things that 
either A) users such as myself will learn to enjoy  or  B) will be improved 
upon to make the application more usable.

kwrite for all its faults (not so many that its useless or repugnant, IMO) 
should not be replaced wholesale with a program that is so new, untried and 
vastly different. i'd say give it time. let kant mature. let kwrite stay 
where it is. when kant is at a point that most everyone is using it and few 
if any are using kwrite, then replace it.

keeping kwrite doesn't add any workload to the developers as long as they 
agree that it is "finished" and no more features are to be added and only 
especially agregious bugs (were any to be found) will be fixed. 

just my 0.02

-- 
Aaron Seigo

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