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

[lupus dei unipd it]

On Wed, Sep 03, 1997 at 01:23:57PM -0400, owt1@cornell.edu wrote:
> 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 

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.

> 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

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

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

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

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

See above: I need a table as big as the screen. The only missing thing in
GtkTable is add/remove col/row.

> Plus GtkTable just isn't optimized 
> for drawing portions of huge tables.

Is this true also for say a 30x10 table?

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

> Again allowing arbitrary 
> columns to be locked in place (as opposed to just the first N) is 
> probably making things unnecessarily complicated.

I agree with this: but we can try to find a viable solution....

lupus

-- 
------   
--      Molaro Paolo  lupus@dei.unipd.it    lupus@maya.dei.unipd.it
------  Mamge', mange': nu sei chi ve mangia'. [FdA]