Re: grid widget (was Re: possible removal of GtkWrapBox)
- From: Tristan Van Berkom <tristanvb openismus com>
- To: Havoc Pennington <hp pobox com>
- Cc: gtk-devel-list gnome org
- Subject: Re: grid widget (was Re: possible removal of GtkWrapBox)
- Date: Thu, 07 Oct 2010 23:48:01 +0900
On Thu, 2010-10-07 at 10:03 -0400, Havoc Pennington wrote:
> Oh, another thing to have is probably h-spacing and v-spacing for the
> grid-wide space between rows and columns. For per-column or per-row
> spacing you could use a margin or a spacer widget placed on that row
> (?)
>
> If not clear the idea of the exercise I was doing is to figure out how
> you'd naturally describe a layout, say to another person, in logical
> terms and without redundancy.
>
> So examples of things I think you would not do if talking to a person
> or just thinking logically include:
> * doing the pack_end widgets backward
> * positioning widgets using grid coordinates
>
> One litmus test for "too much redundancy" is if you have to change two
> lines to add or remove a widget. I think to put another widget on a
> row or to add another row, you should be able to add one line of code
> without changing other lines, at least in the typical case. Similarly
> to remove a widget or row, you should just delete the corresponding
> line of code.
>
> GtkTable requires you to change both the table constructor (overall
> table size) and _then_ possibly re-number a bunch of the other
> children, so it epic fails this litmus test.
>
> Another idea, the "cursor" thing could be done explicitly:
>
> GtkGridCursor cursor;
> gtk_grid_cursor_init(grid, &cursor, row=0);
> gtk_grid_add_row(grid, &cursor, child);
>
> But it seems like extra typing for not much good reason.
Just an initial comment (alarm ringing in my head), I really
do like the idea of using a 'cursor' API when it comes to
writing out UI code by hand.
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).
Reason for this being that:
a.) Making a GtkBuilder description using a cursor will be
cumbersome, it will be heavily dependant on the ordering
of children inside a container
b.) It will be a whole can of worms to support this container
from Glade without child packing properties. Currently Glade
relies heavily on these, by saving copies of packing property
states to be re-applied at undo/redo/paste time, setting
initial packing properties on project widgets freshly
replacing placeholders (and the list goes on).
Regards,
-Tristan
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]