Re: Extended Layout incubator branch.

[Tristan Van Berkom <tvb gnome org>]

On Fri, Apr 23, 2010 at 11:16 PM, Matthias Clasen
<matthias clasen gmail com> wrote:
> On Wed, Apr 21, 2010 at 4:04 AM, Tristan Van Berkom <tvb gnome org> wrote
>
>>  I've managed to get the base feature set of the native-layout
>> branch working and in a usable state.
>
> Tristan, thanks so much for getting this this far.

Thanks for looking at the patch :)

>
> So far, I have found two things that don't seem to work quite right:
>
> 1) In testellipsize, when rotating without any ellipsization, the text
> just 'rotates out' of the allocation, whereas in ellipsized modes, the
> allocation is grown to accomodate the rotated label, as far as
> possible.
>
> 2) The 'flipping' example in testgtk shows trouble with RTL labels.
> The are drawn outside of the button thats supposed to contain them.

These should not be hard to fix, the problem here IMO is too
many exclusive conditions in GtkLabel (this ends up with misplaced
'if' statements and then one feature misses out on a step. In the
case of the rotating label you mention above; I'm sure I broke that
while fixing the transform for vertical wrapping labels).

If I had a whole day or two to focus on GtkLabel right now I
would try to just allow every parameter of the GtkLabel to
always have an effect (and in this way avoid branching
statements depending on how the label is configured).

This would imply supporting simultaneous ellipsizing word-wrapping
labels that can be rotated to any angle and still know how do report
correct minimum and natural widths and heights.

I also forgot to mention that the label does not currently
support the wrapping rotated label or the ellipsize rotated
wrapping label... or even the plain old: wrapping up to the
minimum width-chars and then ellipsize shrink from there...

>
> As for the code itself,  the one observation I have so far is that
> most implementations of get_desired_width/height seem to be in terms
> of a get_desired_width function taking an extra orientation parameter.

Right,
   the important part here was to have the widgets respond to the
api in two passes. When refactoring the majority of the code that
was doing get_desired_size() --> get_desired_width()/height(); using
an orientation parameter for that call just saved me a lot of time.

Otherwise there's no reason they should not just be proper
separate functions get_desired_height()/get_desired_width().

>
> And I wonder if you have any example involving a combination of
> horizontal and vertical size groups. It seems to me that a wfh widget
> should have the potential to link those together and cause interesting
> cycles.

I have not tested that scenario no.

The result should be that each h4w/w4h widget in the group will request
an equal minimum size in each orientation; this will cause resize cycles
where needed and should stop once every widget has been told to grow
up to the minimum size. i.e. the recursing should stop at a reasonable
size and not grow to infinity.

But again no, I have not tested that and it could cause some nonsense if
not treated right.

>
> What's up with  #if __I_HAD_A_MILLION_DOLLARS__ ? You seem to be
> treating h and v boxes differently there.
>

Eeek sorry that made it that far ;-)

That was an "#if 0" in the context of: "We would really love to run the code
that follows but we cant on planet earth".

We should be able to remove that #if now and the fancy calculation
to get the collective widths for the height of a vbox should work with
vertical labels inside *and* with horizontal ones.

Note this will now work for the same reason w4h and h4w will work
together, because of the rule:

   If your widget does h4w but not w4h: when get_desired_height() is
   called; the height for the minimum width must be returned.

   This height may seem to be a large value at times, nevertheless its
   correct. The get_desired_height() API is specific to a w4h
   request; A h4w widget must ensure the height needed to fit its
   minimum width when being allocated in w4h mode.

Since that discovery was made quite late in the game, I was late
in updating that portion, although I expect it to run fine now.
(even on planet earth).

> I'll also point out that docs/reference/gtk/tmpl/gtkcontainer.sgml has
> a section explaining 2-pass size allocation. That should probably be
> updated to reflect the new way of doing things.
>

And GtkLabel docs regarding width-chars and max-width-chars also
need updating...

As much as I'm tempted to look at this right now, and I really am;
I have to work really hard on something else for at least a month
starting a few days ago. I'm going to try to find some spare time
to look at this but it wont be for another week unfortunately.

Cheers,
    -Tristan