Re: [gtk-list] Re: Tabular data widgets [design thoughts]
- From: lupus dei unipd it
- To: gtk-list redhat com
- Subject: Re: [gtk-list] Re: Tabular data widgets [design thoughts]
- Date: Thu, 4 Sep 1997 16:08:42 +0200
On Wed, Sep 03, 1997 at 01:23:57PM -0400, firstname.lastname@example.org 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....
-- Molaro Paolo email@example.com firstname.lastname@example.org
------ Mamge', mange': nu sei chi ve mangia'. [FdA]
] [Thread Prev