[Registrar] Shutdown Status window isn't font sensitive (easy)

[diver]

Shutdown Status window isn't font sensetive (see screenshot). Tested with rev16399.

[diver]

Shutdown Status window

[nielx]

Move to the correct component.

This also qualifies as an 'easy' bug.

[pieterpan]

Ok, so I figured, this one is easy. But I can't figure it out at all... The code in ShutDownProcess.cpp seems fine:

fTextView->SetText("two\nlines");
int textHeight = (int)fTextView->TextHeight(0, 1) + 1;

This is then used to position the elements below the textview. This works with font size in the fonts preflet is 12 (default). Now when I change the font size to 18 (biggest) and reboot, all of a sudden only one text line appears instead of two. (Which is the original problem of this ticket) So to see what is going on, I have modified it in such a way that it also prints the size returned by TextHeight to the resulting string in SetText. The strange part is that TextHeight(0,1) returns a SMALLER value for a larger font! See both screenshots attached. (please ignore the second 0. I looked at TextHeight, but I can't see the problem. It must be in there somewhere... Also, try font size 13 and the window becomes infinitely big... Probably TextHeight returns something strange there... The code there is a little over my head, and it is late.

[anevilyak]

One thing that does immediately seem odd from looking at TextHeight()'s implementation is it seems to reference an out of bounds line:

float height = (*fLines)[endLine + 1]->origin

• (*fLines)[startLine]->origin;

Unless there's some trick I'm missing, that will only work if endLine is not in fact the last line in the view, which it is here. If that's the case it's entirely possible it's getting back a garbage value, though I'm somewhat surprised it's not crashing if that's true.

[pieterpan]

I looked at the way that I think the whole fLines is set up, I think it actually stores an extra line, maybe for code simplification. Say you have 2 lines: line 0 and line 1. It will actually store line 0, line 1 and line 2. Now the total text height is the origin of line 0 to the origin of line 2. However, this does not explain the strange values we get. Anyway, that code is rather involved, perhaps someone who worked on it could examine it?

One of the problems with this code is that it assumes that the text will fit inside the window (determined by the width of the buttons etc, and that it will do so in 2 lines... Probably for a long app name and big font this does not apply. So it should probably also factor in the width of the textview. Or just use the layout system.

[stpere]

Committed a fix in hrev32501. I think the problem had something to do with the way the wrapping happened. The text is put in a very small TextView (10x10), and with large fonts, we get this :

T <- a very tall line
w <- a short line
o

l
i
n
e
s

And the size is only computed for the first 2 lines. Then we resize the whole text view based on those stats. What I did was to disable the WordWrap the time we get the size, then enable the WordWrap again.