Re: Text-widget

[Owen Taylor <otaylor redhat com>]

Derek Simkowiak <dereks@kd-dev.com> writes:

> > The text-widget has some Function-keys predefined (like ctrl-u to delete a
> > line). Is there any possibility to change those from my program or do i
> > have to make a special version of the widget for my program ???
> 
> 	Those are hard-coded into the widget.  See gtktext.c, in the
> function "gtk_text_key_press" to modify them.
> 
> 	I don't know if those should be modified to send signals, which
> can then be attached to callbacks, or what.  Perhaps it's better to ignore
> them completely, and let the application worry about them?  Suggestions
> are welcome.

The mechanism in GTK+ for this is GtkBinding. The GtkEditable widgets
were never converted over, but it was designed with this in mind.
The biggest users right now are the GtkCList and GtkMenu code.

> 	Incidentally, the GtkText widget has some serious problems which
> make it insufficient for a serious text editor.  The design is sound (and
> the original author did an awesome coding job)

Well, I think Josh had some good thoughts. But the design goals 
ended up not being very feasible, and the design, in practice turns
out to STINK. Josh has agreed that it really needs to be rewritten
completely from scratch.

To give some history, the primary design goal of GtkText was to have
a low per-character overhead. Apparently some testing was done
on the Tk text widget that indicated that it was using ~3x as much
memory as was needed to store the characters itself, and Peter
or Spencer told Josh that they wanted a text widget that would
do better in this regard.

For this reason, the original idea was only to store a very minimal
amount of information for the characters currently on the screen
and discard it. (The LineStartCache was meant to be a cache, not
just a big list of all the lines). In practice, it turned out that
creating the LineStartCache was the biggest performance bottleneck,
so I decided against discarding information from the cache when
I worked on finishing up what Josh started so that editing could
be enabled.

So, the actual goal of saving memory is not achieved very well - we
just have a widget with bad data structures for the way it actually
works.

The reason why GtkText is completely unmaintainable is that there
are three separate data structures being kept in sync:

 The gapped text buffer
 The property list
 The line start cache

This wouldn't necessarily be bad if they were separated out
into conceptually separate objects with clean interfaces. But
instead, they are woven together throughout the code in
a truly horrific manner. If you think you really understand
GtkText, please go and look at correct_cache_insert() for
a while. 

It looks sort of impressive to see the number of assertions
that Josh put into GtkText, until you've spent a few hours
trying to figure out why one of them is failing only to realize
that the insertion was _incorrect_. (And this has happened
to me more than once.)

Basically, if a design is so complex that the assertions one adds
are incorrect, then I cannot in any way consider it sound.

> , but the widget is unfinished, there are some bugs, and the
> rendering pipeline is too slow.  Just maximize a GtkText and scroll
> through some text to see what I mean.

Hmm, actually, no I don't. I tuned GtkText to perform decently
on a 7000 line text file on a P133-class machine, and I really
can't detect any noticeable at all slowness on such files on
the machines I have available to me. But the operation that has
always taken the most time with GtkText is doing the initial
size and line-wrap 

The performance problems I'm most familiar with in GTK+ text
have to do with the way it scrolls in response to insertions
and deletions. (Hit the "Insert Random" button in the GtkText
example in testgtk to see what I mean.) But that is because
it scrolls line-by-line to the insertion location, and the speed
of line-by-line scrolling, though plenty fast for interactive
use, isn't so fast as to make this anything other than amazingly
slow.

> 	I'm working on the problem.  I'm currently desiging a new
> rendering pipeline

pipeline? I don't see how this term makes any sense here.

> , which should make horizontal scrolling easy to
> implement (and response times faster).

Horizontal scrolling would be easy enough to implement in the 
current framework for rendering. Especially as it really
wouldn't hurt to just render the whole line anyways and let
it get clipped. 

Regards,
                                        Owen