Re: Extended Layout
- From: Tristan Van Berkom <tvb gnome org>
- To: Murray Cumming <murrayc murrayc com>
- Cc: Jan Arne Petersen <jpetersen openismus com>, Owen Taylor <otaylor redhat com>, gtk-devel-list gnome org
- Subject: Re: Extended Layout
- Date: Fri, 16 Apr 2010 10:36:43 -0400
On Fri, Apr 16, 2010 at 5:45 AM, Murray Cumming <murrayc murrayc com> wrote:
> On Thu, 2010-04-15 at 15:18 -0400, Owen Taylor wrote:
>> I meant that 'height-for-width' is useful, and
>> 'width-for-height' is a bit of gravy on top.
>>
>> That is, "the behavior of text" is useful, the opposite behavior less
>> useful.
>
> Tristan, so can you make things easier by cutting out that feature,
> while still fixing the UI bugs that we think need extended-layout?
>
I doubt that cutting out the width-for-height API itself will make
things simpler as it shouldnt change the conditions much.
Currently anything that does not explicitly do "width-for-height"
negotiations will return the base minimum and natural value from the
default ->get_desired_width() api, which is what we would do if
we didn't have the "width-for-height" api in there.
That being said, we can go ahead and finish implementing the feature
with the api as is; and then try to enable some widgets who are doing
width-for-height (90 degree rotated text...) and if that breaks things in
any serious way, we could then consider backing out the width-for-height
api.
I really need to spend a good full afternoon looking at gtklabel.c
and making it report the correct default minimum/natural sizes
under all of its settings/conditions. Fixing that; along with implementing
the collective height for width of an HBox algorithm[1] suggested
by Owen; I think should be enough to fix the new geometry
management features.
Regards,
-Tristan
[1] Note that Matthias Clasen also suggested the same algorithm idea
last week, I tried it then; it worked a bit and failed a bit, partially
because GtkLabel default values arent right, partly because I expected
it to work in both orientations/dimensions.
Owen's text here pasted for reference:
for an implementation. I forget the exact details, but I think the basic
idea is just to do the expand/fill calculations based on the minimum and
natural widths of the children. Then based upon the computed child
sizes, compute minimum and natural heights for the children.
>
> --
> murrayc murrayc com
> www.murrayc.com
> www.openismus.com
>
>
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]