Re: griping about development

[Chris Phelps <chicane reninet com>]

> Such as what? The only two I know of are tab support and custom-drawn
> margins (breakpoints, line numbers) but these are both planned and can
> each be implemented in about 1 day.


> You are on crack. ;-) The new widget in GTK took 3-4 months of work,
> split between me and Owen. And it started with the existing Tk
> codebase and design. You don't want to go there. Do something useful
> with your 3-4 months.

While I am willing to spend as long as it takes to get a functional
widget, I have no intention of spending 3 months on it. I have less than
a week in fixing all of the GtkExText problems and re-coding about 65%
of it...

> > It will have gutter pixmap support (for debugging purposes), line
> > numbers, etc.
> 
> 1 day task for the widget in GTK.
> 

If this is so, I will check into it. I originally did not want to use
the tktext port because I figured you and owen would object to adding
extra crap that was not needed for a base widget.

> 1 or 2 day task for the widget in GTK, though I'm not currently
> planning to do it myself.

This is a must. I will look through the new GtkText to see what it would
take.

> The GtkTextView widget in CVS HEAD is fast enough. It also still has
> some optimization room if you wanted to hack on it. Moreover the UI
> never blocks for a user-perceptible time slice, which makes it appear
> to be fast even when it isn't.
> 
> You are just going to end up with Yet Another Gapped Text Buffer
> Widget, and there are dozens out there, several for GTK and many
> others for Qt, etc. that you could port. Look at the one in KWrite for
> example, or as you mention the one in NEdit. This is a problem that's
> been solved 1000 times and solving it again is Useless (tm). If you
> want a gapped text buffer, use one of the GTK widgets, or port NEdit
> to GTK, but it's a pointless undertaking IMHO. I considered the
> KWrite, NEdit, etc. code while writing GtkTextView.
> 
> There are some advantages of a simple gapped buffer widget vs. the
> GtkTextView in GTK+ 2.0, yes, but they are not very compelling for
> something like an IDE. The main advantage is "easy to implement" but
> that isn't relevant since we already implemented things the hard way
> for you. ;-) A gapped buffer also uses less memory and _some_
> operations are faster, others are much slower. A gapped buffer
> probably can't implement incremental reflow easily, without an
> auxiliary data structure that wrecks its less-memory advantage, which
> means you can't get proper Pango support either.

Wasn't planning on doing any pango support at all. It seems like it
would be a waste of time for a code widget.

Well, you have at least succeded in making me question my original
course of action. Im going to spend a few days reading the GtkText code
to see what can be done.

Later,
Chicane