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



On Sun, 2010-10-10 at 17:23 +0900, Tristan Van Berkom wrote:
> On Sun, 2010-10-10 at 02:14 -0400, Matthias Clasen wrote:
> > On Thu, Oct 7, 2010 at 11:30 AM, Tristan Van Berkom
> > <tristanvb openismus com> wrote:
> > > On Thu, 2010-10-07 at 10:55 -0400, Matthias Clasen wrote:
> > >> 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).
> > >>
> > >> To me, what Havoc described really sounds like a layer of convenience
> > >> api or 'gridbuilder' on top of a widget that has child properties
> > >> similar to what my GtkGrid has.
> > >
> > >
> > > Matthias,
> > >   to reply to your previous mail about hfw management in general,
> > > I havent thought out GtkTable management in full detail (or implemented
> > > it) but here are some starting points:
> > 
> > Thanks, Tristan.
> > 
> > I have pushed an initial attempt at hfw in GtkGrid to the branch. It
> > would be great if you could check it out and let me know if I got
> > things halfway right. It seems to work ok for the few simple tests
> > that I've added.
> 
> I looked over the code and tried the test.
> 
> Some comments:
> 
>   - in get_preferred_width() and get_preferred_height() it seems
>     you do the same request regardless of the request mode... it may
>     that you check this somewhere else in your request code but I did
>     not see it.
> 
>     its important in this case when get_height() is called for a
>     height-for-width widget that you return the height for minimum
>     width, the easiest way I found to do this is just to invoke your
>     vfuncs from get_height:
>        if (is_height_for_width) {
>          get_width ( &min_width )
>          get_height_for_width ( min_width, &min_height, &nat_height );
>        }
> 
>   - in get_height_for_width() and get_width_for_height() it seems you do
>     something like the above check... what needs to be done here:
> 
>       a.) in get_width_for_height() for a height-for-width mode grid
> 	  (and the opposite), you need only return the results of
>           get_preferred_width()
> 
>       b.) in get_height_for_width() for a height-for-width widget, I
>           found it was important to ensure you dont request for 
>           something less than the minimum width, so:
> 
>             min_width = grid->get_preferred_width ( &min_width );
>             get_height_for_width ( MAX (min_width, for_width),
>  				  &min_height, &nat_height);
> 
>           Adding scrolled windows/viewports to your test case helps 
> 	  to reveal the need for checking the input width against the
>           real minimum width when doing height-for-width (when
>           scrollwindow tries to request insufficient width, the
>           requested height is generally too much and can be observed 
> 	  by the vscrollbar positions not in sync).
> 
>   - It seems you are storing the allocated/requested sizes in your
>     GridLine structs, I guess this is convenient for your code's clarity
>     but might be confusing to some readers. I think its important
>     to at least comment/note that these allocated sizes must be
>     reconstructed for every request/allocation, in other words the
>     allocated sizes cannot be relied upon in a potential future "draw"
>     implementation, nor can the allocate method rely on sizes
>     resolved in previous request calls.

Hmmm one more thing, 
   this one is more a question about desired/expected 
behaviour. I think that what we want is that if no rows or
columns are expanding... they should all expand; at least
that's what GtkBox does and what I would expect the container
to do, otherwise extra expand space is always left at the
bottom or right size of the Grid. (if the user wants the 
grid children not to expand at all, they should only have 
to pack the whole grid into another container and say that 
the grid does not expand).

Seems that gtk_grid_compute_expand() doesn't do this (nor
does the following allocation code which uses the expand
count to distribute extra space).

Cheers,
       -Tristan

> 
> Cheers,
>         -Tristan
> 
> 
> 
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]