Re: [gtk-list] Re: Tabular data widgets [design thoughts]

[owt1 cornell edu]

On Thu, 4 Sep 1997 lupus@dei.unipd.it wrote:

> With my design you do have an X window, but big at most as the screen.
> The widget maps columns of widgets on this window as needed: when
> you scroll the grid the x windows stays, you map the columns in different
> positions and get the application to provide widgets to fill empty space.

With this scheme it is quite difficult to provide truly smooth 
scrolling without flashing - which I think is an important goal. 
Achieving sufficient smoothness is really important in mantaining the 
"user illusion". I suppose it might be possible for the GtkMisc widgets
to set things up so that there widget->window field was an offscreen 
pixmap -- hmmm -- might have something there...

Though I'm concerned that having to create/destroy widgets for
every displayed cell could be prohibitive.

> The policies I can think of are provided with the folding concept
> and the block/unblock thing. I'm missing something?

One big one is selection (browse/multiple/etc.) It also might be useful
to have a tree widget be able to do interactive folding itself, though
probably not necessary.

> I don't want to use lists to store things: I'd use an hash table.
> This can be also a big win for sparse matrix grids like spreadsheets....

As an example:

Say you have a heirarchical list of your entire filesystem, with the
/usr/local and /etc directories folded (hidden). Now determine what's
the 7000'th row. A flat hash will still be linear in N. (You could
use a tree stored in a hash, but that's no easier to extend to 2D than a 
normal tree)

[ My comment on table performance for large tables ]

> Is this true also for say a 30x10 table?

Try it and find out... But see above for why using a normal table and
adding/removing columns probably isn't a good idea. (And you would have 
to keep track of a lot of extra stuff anyways to handle scrolling
properly)

> > Folding both rows and columns sounds like it would be an efficiency
> > nightmare. (or at least a programming nightmare). 
> 
> We are programmers, aren't we?

Yes, but my time, at least, is limited ;-) Plus stability is a very
important consideration, and one of the best ways of achieving that
is to find the simplest possible solution that satisfies the 
requirements. (Not excluding the possibility that if we're clever
enough folding both rows and columns could be the simplest solution...)

Regards,
                                      Owen