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



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]