FYI: GtkText brainstorming: further modularity

[Derek Simkowiak <dereks kd-dev com>]

      For those interested,
	I prefix these messages with FYI because I don't want to waste the
time of people not following the new GtkText development.  If I have an
actual question or something important to say I won't prefix it with FYI.
If these messages are too trivial for the gtk-devel-list, please just let
me know and I will stop sending them.

	I've been working on the DataBuffer struct and API, and it's
rapidly beginning to look like it needs more structure.  The Renderer
struct is also looking like it might need more structure.

	The DataBuffer currently has a myriad of variables and GLists
relating to the gapped text buffer, the propery list, and the tab list (a
simple linked list of tabs and a default tab value, as originally
implemented in GtkText).

	As it currently stands, the functions for the gapped buffer, tabs,
and property list will all need to take a "DataBuffer" struct pointer as
their first argument.

	So it may be time to add another layer of abstraction, by having a
separate gapped text buffer struct, a tab list struct, and a property list
struct.  I'm imagining a hierarchy close to this:

GtkText
  +--DataBuffer
  |    +--TextPropertyList
  |    +--TabList
  |    +--GappedTextBuffer
  |    +--TextSelection
  |
  +--Renderer
       +--Cursor
       +--FontCache   // height/width dimensions for faster redraw algorithms
       +--LineCache   // May be dropped ...(?)

	The thing that brought me to this is that I want to, eventually,
enable rectangular selection (selection regions of text by columns and
rows, as in Nedit) in my application.  To do that, I don't want to start
messing with the DataBuffer struct and API.  I only want to mess with the
"TextSelection" struct and API, add a GtkBinding, and leave the rest of
the code untouched.

	I also imagine things like custom cursors, the addition of line
numbers (which will be a feature of my app), and things like bookmarks
and/or breakpoints next to lines (as implemented in TextPad [win32] and
Code Medic, respectively).  It would be nice if I already had another
layer of abstraction to add, say, a "LineFeatures" struct under the
Renderer.

	Unfortunately, we are now three layers of abstraction deep for a
single widget, which bothers me.  Anyone wanting to modify or improve the
widget will have (so far) 9 different structs and corresponding APIs to
learn.  Is that too much?  Will code that looks like


void renderer_draw_line(Renderer* renderer, guint line_number) {

    if (renderer->line_features->show_numbers == TRUE) {
         line_features_prepend_line_number(renderer->line_features, 
					renderer->line_features->font);
    }
[...]
}

	...be too distracting?  The alternative is lines like 

void renderer_draw_line(Renderer* renderer, guint line_number) {

     if (renderer->show_numbers == TRUE) {
         renderer_prepend_line_numbers(renderer, line_number,
				    renderer->line_number_font);
     }
[...]
}
	While the code is easier to modify with more abstraction, it's
also more difficult to follow and read.

	I need to think about this some more...


--Derek