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

[owt1 cornell edu]

On Wed, 3 Sep 1997 lupus@dei.unipd.it wrote:

> You don't want to reinvent the weel: a text string should be a gtklabel and a
> pixmap a gtkpixmap...., so, IMHO, a cell of the grid can be empty or contain
> a widget.

You may be right about this - it is a bit simpler and would allow people
to set the font and alignment just as they would normally. On the other
hand, I don't want to actually have an X window as big as the table, so 
there are advantages to having more control over the drawing. (As Raph 
Levien has pointed out in the past, combining manual drawing with 
embedded buttons/entries/etc. can lead to drawing lags, but I think this 
isn't a huge problem here)

> I think a hierarchy of widgets is unnecessary:
> we can use a single widget.

There are two reasons to have a hierarchy. What you are mainly addressing
is the concept of storage. Aside from this, there is also the question
of user-interface policy. I'm personally of the opinion that there is 
more than one type of interface policy needed here, and that it would
be cleaner to separate them into separate widget classes then to make
one widget that can be configured to do everything.

Even for storage, I'm not sure that doing it just one way is best. For
efficient operations on medium size lists (100-1000 rows) you probably
need to store things in tree form. (Especially with heirarchical folding)
This might be an OK way to store things in general, but I'm not sure
about this.

> This widget can also derive from GtkTable, I think.

I suspect not, at least without completely rewriting GtkTable. GtkTable
needs an enclosing X window which is as big as the logical area. (And X 
windows are limited to 32768x32768). Plus GtkTable just isn't optimized 
for drawing portions of huge tables.

> The gtkgrid widget has a [xy]scroll method (this can be called directly
> or by means of scrollbars: this gtkgrid thing shoul be coupled with a
> scrolled window widget...): it shifts the rows and columns in itself
> and if needed emits a "request" signal.

This sounds like the Tk way. This is probably better done with 
adjustments, like GtkText or GtkScrolledWindow. (But GtkScrolledWindow
isn't useable here because it actually scrolls a window)

> *) A widget can span multiple columns/rows (this is like wrap/nowrap in vi).
> *) You can hide/show some rows/columns (folding).
> *) Some row/column can be blocked: it doesn't shifts with the rest of the cells.

Folding both rows and columns sounds like it would be an efficiency
nightmare. (or at least a programming nightmare). Again allowing arbitrary 
columns to be locked in place (as opposed to just the first N) is 
probably making things unnecessarily complicated.

Thanks for the comments. I've mostly commented on what I disagree with above,
but I agree with a lot of what you say too. Figuring out a good 
compromise between simplicity, generality, and efficiency is not an easy 
task here.
                                   Owen