Re: Gtk{Tree,List} replacement proposal

[Jonathan Blandford <jrb redhat com>]

Guy Harris <gharris@flashcom.net> writes:

> 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.

It's a property of the model -- in that each model has a column with a
name and a number associated with it.  However, you can always replace
the widget in the button with your own label if you would like?

> 	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)?

Yes.  You can rearrange columns and hide them as needed.

> 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.

ugh.  This is exactly the problem I'm hoping to solve...

> 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.

Then why don't you start writing it against 1.4?  You can test out the
new code, and give me some feedback.  I expect you'll find it worth your
time, as doing what you propose with a hacked clist will suck, big time.

Thanks,
-Jonathan