> I. Consistently use gtk+-specific terminology, or not.
>
> I think if we're going to have hbox/vbox
> (which smell very strongly of gtk+), we oughta use table
> and not grid.
> and maybe spinbutton instead of spinner.
>
> or, use grid everywhere and if grid::height == 1, the
> implementation
> may use an hbox for efficiency, etc.
>
agreed, and i realize that my first proposal was terribly simple. (just to
say that there was Qt terms, where you have vbox, hbox and grid. I assume
only Grid/table is really needed. HBOX and VBOX is just syntactic sugar ,
thus irrelevant here.
The features we may need are :
multicolumn & multirow widgets
spacing between row /column : can be a blank multicolumn or multirow
widget extendable widgets / fixed-size widgets
nestable packing
...?
first example :
<table vhomogenous = "true" hhomogenous = "false">
<widget1 ... />
<widget2 ... />
<widget3 ... />
<newline/>
<multispan row="2" column="4">
<widget> # only one widget here !
<multispan/>
</table>
or we may have the (maybe cleaner in a pure description as here) Tk/Qt
layouts approach of setting widgets on a table :
each widget can have the following attributes :
row
column # default to 0
rowspan # DEFAULTS TO 1
columnspan # DEFAULTS TO 1
strechfactor # defaults to 1, can be 0 -> no strech, other values
are relative to each other.
row/column indexes are relative to each other
it may be the simplest way of doing things : no nesting, but
variable-sizes-proof.
What do you think ?
