Re: grid widget (was Re: possible removal of GtkWrapBox)
- From: Tristan Van Berkom <tristanvb openismus com>
- To: Matthias Clasen <matthias clasen gmail com>
- Cc: gtk-devel-list gnome org, Havoc Pennington <hp pobox com>
- Subject: Re: grid widget (was Re: possible removal of GtkWrapBox)
- Date: Sun, 10 Oct 2010 17:23:13 +0900
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.
Cheers,
-Tristan
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]