Opened 14 years ago

Closed 10 years ago

#169 closed bug (fixed)

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

Reported by: diver Owned by: stpere
Priority: normal Milestone: R1
Component: Servers/registrar Version: R1/pre-alpha1
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description (last modified by nielx)

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

Attachments (3)

shutdown.PNG (10.5 KB ) - added by diver 14 years ago.
Shutdown Status window
FontBig.png (11.1 KB ) - added by pieterpan 11 years ago.
FontNormal.png (9.3 KB ) - added by pieterpan 11 years ago.

Download all attachments as: .zip

Change History (13)

by diver, 14 years ago

Attachment: shutdown.PNG added

Shutdown Status window

comment:1 by axeld, 14 years ago

Owner: changed from sikosis to bonefish

comment:2 by korli, 14 years ago

bug_group: developers

comment:3 by diver, 13 years ago

Summary: Shutdown Status window isn't font sensetive[Registrar] Shutdown Status window isn't font sensetive

comment:4 by diver, 13 years ago

Summary: [Registrar] Shutdown Status window isn't font sensetive[Registrar] Shutdown Status window isn't font sensitive

comment:5 by nielx, 12 years ago

Component: - ApplicationsServers/registrar
Description: modified (diff)
Platform: All
Summary: [Registrar] Shutdown Status window isn't font sensitive[Registrar] Shutdown Status window isn't font sensitive (easy)

Move to the correct component.

This also qualifies as an 'easy' bug.

comment:6 by pieterpan, 11 years ago

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.

by pieterpan, 11 years ago

Attachment: FontBig.png added

by pieterpan, 11 years ago

Attachment: FontNormal.png added

comment:7 by anevilyak, 11 years ago

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.

comment:8 by pieterpan, 11 years ago

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.

comment:9 by stpere, 10 years ago

Owner: changed from bonefish to stpere
Status: newassigned
Version: R1 development

comment:10 by stpere, 10 years ago

Resolution: fixed
Status: assignedclosed

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.

Note: See TracTickets for help on using tickets.