Re: grid widget (was Re: possible removal of GtkWrapBox)

[Havoc Pennington <hp pobox com>]

Hi,

On Thu, Oct 7, 2010 at 10:48 AM, Tristan Van Berkom
<tristanvb openismus com> wrote:
> However I would really appreciate it if a widget's placement
> inside a container can still be clearly introspected and defined
> with container child properties (in other words I think the widget
> should be built with child properties and the 'cursor' be a
> convenience API layer of sorts).
>

I agree with this (and almost mentioned it).

I guess what I'd say though is, I think the "gridbuilder" should be
the primary/expected API when packing with code, and taking the API
design "top down," the child properties have to be designed such that
the nice gridbuilder is possible.

I wouldn't really do the gridbuilder as a literal separate API
("gtkgridbuilder.h"). I think it would add typing and confusion. I'd
say go ahead and make it gtk_grid_add_left(), etc. which would be the
first API people go for. And then the "raw" child props API could even
be _just_ properties (use gtk_container_add_with_properties etc) or
just a couple of low level functions that would be documented as "you
probably don't want to use this"

One question on gridbuilder is whether it's "persistent." For example,
it could be that as I'm doing add_left(), add_row(), etc. that is just
setting fixed grid coordinates. And then once the grid is created, I
can't use the gridbuilder stuff to modify it. Or, it could be that as
I do add_left(), add_row(), etc. that is saving a conceptual list of
actions and on each relayout, that conceptual list of actions is
converted to a table of cells.

I think it's maybe the second thing for two reasons:
* you can then use "gridbuilder" API to modify the table later. an API
could allow you to "set the cursor" to a particular row and next to a
particular widget, then you start "gridbuilding"
* you need to autocompute table size, so when doing add_left, add_row,
etc. you don't know the actual cell coordinates yet

It isn't totally clear to me what the right child properties are.

Kind of the way I'd approach this would be to have some sample layouts
that were typical and Should Be Easy(tm), write nice, logical,
non-redundant code that should produce those layouts, then figure out
how to implement the widget to support said nice code.

Hmm. One other goal ideally achievable, is that a simple one-row box
should not have a ton of CPU or memory overhead.

Havoc