Re: Gtk{Tree,List} replacement proposal

[Guy Harris <gharris flashcom net>]

On Mon, Jul 03, 2000 at 06:14:56PM -0400, Jonathan Blandford wrote:
Some questions about the TLView:

	Is the set of columns being displayed in a list a property of
	the model or of the view?  I'd vote for it being a property of
	the view - the model might have columns "Foo", "Bar", and
	"Bletch", but you might want to have one view showing "Foo"
	followed by "Bar" and another view showing "Bletch", "Bar", and
	"Foo", in that order.

	Can columns be added to, removed from, and moved in a view? 
	I.e., in the example in the previous paragraph, could the
	application showing those two views allow the user to specify
	that the first view should become "Bar" followed by "Foo", or
	"Bar" followed by "Foo" followed by "Bletch", and the second
	view should become "Bletch" followed by "Bar", without having to
	destroy either of the views and re-create them (or do anything
	else that's linear in the number of rows in the view)?

I'm planning, at some point, to make a modified version of the CList for
use in Ethereal, which would *not* store any of the strings displayed in
the columns; instead, to display a row, it'd, for each column to be
displayed, call a function associated with the CList, passing it a
pointer associated with the row and an indication of what column was to
be displayed, and get back a string to draw in that column.  This would:

	1) allow me not to allocate any string data at all for many of
	   the columns in Ethereal's display, saving memory, and saving
	   CPU time when reading in a capture and creating the list;

	2) allow Ethereal to change which columns are being displayed
	   without having to reconstruct the CList - just tell the list
	   what the new set of columns to display is, and tell it to
	   redisplay the list.

When GTK+ 2.0 sweeps 1.x from the face of the earth (i.e., when Ethereal
no longer need worry about supporting 1.x), I'd prefer not to have to
replace the new tree/list view and model code to implement that - having
to subclass them would be tolerable, I suspect, although not ideal.