Re: FYI: GtkText design progress

[Derek Simkowiak <dereks kd-dev com>]

> wondering: how do you know where in the gaped text
> buffer do distinct lines start?

	I'm still working on it (read: I don't know :).  A line start will
only happen in one of two places: after a \n, or after a word wrap.  I'm
not sure the line cache is the best way to solve the problem.

[re: splitting the implementation into several files...]
> no one is going to stop you from that (not implying that this would
> be the sort of split up you should/want to make).

	I may actually do this later on, but for now I want to have the
simplicity of maintenance of a single header and .c file.  I imagine that,
when it's done, several of the existing project (gIDE, gEdit, etc.) will
want to use the updated GtkText, and it'll be easiest on them if they can
just add the two files.

	Plus, I think something like a gapped text buffer may be more
suited to Glib than to Gtk+.

> if you're expecting to have huge numbers of text properties around and
> need to maintain the property list on your own anyways, don't allocate
> extra GList nodes for this, but put TextProperty *prev, *next; pointers
> at the begining of your structure right away (the necessary bits for
> list and tail cache maintenance are already waiting in glist.c and
> queue.c to be cut'n pasted ;).

	Why?  GList has an established, easy to understand API and is
well-tested code.  Why re-invent the wheel?

> this is one important thing you need to have specified in the forefield.
> one user_data pointer is seldomly sufficient, there will always be multiple
> domains wanting to set specific properties on text portions. 

	Will there really be multiple domains wanted to modify the data in
a single application?  I'd think that the user_data would point to a
struct complex or large enough to hold any data the user needed for that
application.

	Also, FYI, the user_data API and pointer were added there for the
gIDE project, by the GtkSCText widget (which I am using for my base code).


--Derek