Re: [gtk-list] Tabular data widgets [design thoughts]
- From: lupus dei unipd it
- To: gtk-list redhat com
- Subject: Re: [gtk-list] Tabular data widgets [design thoughts]
- Date: Wed, 3 Sep 1997 14:45:22 +0200
On Fri, Aug 29, 1997 at 11:04:00PM -0400, Owen Taylor wrote:
> - For applications like the first two, the widget shouldn't need to
> store the contents of every row or cell. (Otherwise there would be a
> huge increase in memory usage and startup-time
> - Each cell should be able to display
> * a text string, clipped to the cell boundaries
> * a pixmap
> * an embedded widget
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
> +-- GtkRows (need a better name)
> | \-- GtkHList
> \-- GtkSpreadsheet
I think a hierarchy of widgets is unnecessary:
we can use a single widget. This widget can also derive from GtkTable, I think.
In the gtk_grid_new call you pass at least 4 parameters:
hintx, hinty and maxx, maxy
hintx and hinty are the columns and rows for which the widget actually
stores a widget pointer.
maxx and maxy are the max column and row index.
A simple application uses hintx == maxx and hinty == maxy so it doesn't need
to respond to request_row or request_column signals emitted by the widget (more
on this later).
A spreadsheet application or a database reporter or editor builds a gtkgrid
with hinty say 30 (how many rows can fit in a screen) and hintx say 10 (how
many columns can fit in the application's window).
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.
The application should connect to this signal and pass the needed widgets
(maybe in a list or an array). gtkgrid requests at most hintx widgets
per row and hinty widgets per column.
A row-oriented application uses hintx = maxx (the widget doesn't scroll
in the x-direction) and connects only to the "request_row" signal.
> A descendent of GtkGrid specialized for displaying 2D data, with more
> policy (and storage?) [ I don't have too clear an idea what is needed
> here ]
The widget should work a bit like a display engine for a folding text editor:
there is the data (in the text buffer) and the display.
The display holds a partial copy of the data; the data displayed needs not
be contiguous (folding). Here the display is the gtkgrid widget. So:
*) 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.
Rows and columns should be allowed to expand/collapse or have a
user-defined size (indipendent from the requisitions of widgets they contain).
-- Molaro Paolo email@example.com firstname.lastname@example.org
------ Mamge', mange': nu sei chi ve mangia'. [FdA]
] [Thread Prev