Opened 13 years ago

Closed 12 years ago

#750 closed bug (fixed)

[Desk Calculator] text overlapping

Reported by: diver Owned by: jackburton
Priority: normal Milestone: R1
Component: Kits/Interface Kit Version:
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description (last modified by jackburton)

*1. If you type several letters in Desk Calculator, then back to beginng of textview and type another (e.g. in upper register) several letters and repeat this several times, soon you will see that some letters overlapping another.

2*. rm /boot/home/config/settings/DeskCalc_settings type "11111", now you should see that ibeam cursor in the beginng of textview will not be erased and there are 2 cursors...

Attachments (2)

deskcalc3.PNG (6.7 KB) - added by diver 13 years ago.
text overlapping
deskcalc2.PNG (5.5 KB) - added by diver 13 years ago.
double cursor

Download all attachments as: .zip

Change History (7)

comment:1 Changed 13 years ago by diver

Also i think Desk Calculator is a good test case for BTextView as you could see various problems resizing deskcalc, you could even see sometimes semitransparent text...

Changed 13 years ago by diver

Attachment: deskcalc3.PNG added

text overlapping

Changed 13 years ago by diver

Attachment: deskcalc2.PNG added

double cursor

comment:2 Changed 13 years ago by jackburton

Component: GeneralUser Interface/InterfaceKit
Description: modified (diff)
Platform: All
Status: newassigned

comment:3 Changed 13 years ago by jackburton

Looks like there's a rounding issue in the text width calculation. Disabling the use of WidthBuffer fixes the problem, but I suspect it's related to another thing, as _BWidthBuffer_::StringWidth() is simply less accurate in its calculation and isn't subject to the same rounding as the values returned by BView::StringWidth(). Looking into it...

comment:4 in reply to:  3 Changed 13 years ago by jackburton

Replying to jackburton:

Looks like there's a rounding issue in the text width calculation. Disabling the use of WidthBuffer fixes the problem, but I suspect it's related to another thing, as _BWidthBuffer_::StringWidth() is simply less accurate in its calculation and isn't subject to the same rounding as the values returned by BView::StringWidth(). Looking into it...

Apparently I was wrong. The problem is that the app_server only supports B_STRING_SPACING and nothing else. This spacing mode is not compatible with how _BWidthBuffer_ works. I've disabled its use in hrev19004 within BTextView and this problem is gone. I'll keep this bug opened as a reminder, though.

comment:5 Changed 12 years ago by jackburton

Resolution: fixed
Status: assignedclosed

no longer applies

Note: See TracTickets for help on using tickets.