Opened 4 years ago

Closed 3 years ago

#16476 closed bug (fixed)

[Tracker] text rect is off while renaming desktop icons

Reported by: diver Owned by: jscipione
Priority: critical Milestone: R1/beta3
Component: Applications/Tracker Version: R1/beta2
Keywords: Cc:
Blocked By: Blocking: #16519, #16799
Platform: All

Description

Possibly related to hrev54496.

Text labels are shifted if you try to rename a file or folder on the Desktop.

Attachments (2)

BTextControlBug.cpp (2.1 KB ) - added by X512 3 years ago.
Similar problem in BTextControl. It worked fine before hrev54549.
tracker.png (134.2 KB ) - added by diver 3 years ago.

Download all attachments as: .zip

Change History (19)

comment:1 by jscipione, 4 years ago

Resolution: fixed
Status: assignedclosed

Reverted in hrev54530/hrev54531. Fixed again in hrev54549.

comment:2 by diver, 4 years ago

Resolution: fixed
Status: closedreopened

There is still something wrong when renaming files with long filenames.

comment:3 by jscipione, 4 years ago

If a filename is long enough to be truncated with an ellipsis, then the edit text view is made large enough to fit the full text, but it doesn't change the file name to be the full un-truncated version until you push an arrow key. There does appear to be a bug here. The modifications I made to the text view are right, and there appears to be another bug. We have to replace the truncated version with the full version when edit name is activated. We could theoretically wrap the the text view to multiple lines, but that may be more complicated.

comment:4 by diver, 4 years ago

Blocking: 16519 added

comment:5 by pulkomandy, 3 years ago

Milestone: UnscheduledR1/beta3
Priority: normalcritical

by X512, 3 years ago

Attachment: BTextControlBug.cpp added

Similar problem in BTextControl. It worked fine before hrev54549.

comment:6 by jscipione, 3 years ago

The BTextControlBug.cpp file you posted has been a helpful tracking down BTextView bugs/differences to BeOS. I took the file you posted above BTextControlBug.cpp, and I made a few small modifications. Firstly I changed SetViewUIColor(...) to SetViewColor(ui_color(...)) just so that it would compile on BeOS, and then secondly I called PrintToStream() on the text rect after the BTextControl was created and then again after calling SetText(). Here's what I got on BeOS:

before SetText()

BRect(l:4.0, t:4.0, r:1019.0, b:-4.0)
BRect(l:4.0, t:31.0, r:1019.0, b:23.0)
BRect(l:4.0, t:58.0, r:1019.0, b:50.0)

after SetText()

BRect(l:0.0, t:0.0, r:60.0, b:13.0)
BRect(l:0.0, t:0.0, r:59.0, b:13.0)
BRect(l:0.0, t:0.0, r:59.0, b:13.0)

So you can see that on BeOS it is fixing up of the text rect. Here is the same program running on Haiku:

before SetText()

BRect(l:4.0, t:4.0, r:1361.0, b:-4.0)
BRect(l:4.0, t:36.0, r:1361.0, b:28.0)
BRect(l:4.0, t:68.0, r:1361.0, b:60.0)

after SetText()

BRect(l:0.0, t:0.0, r:0.0, b:18.0)
BRect(l:0.0, t:0.0, r:0.0, b:18.0)
BRect(l:0.0, t:0.0, r:0.0, b:18.0)

Aha! On Haiku we don't try to fix the text rect if it is 0 width. So this is the reason that we are getting this odd vertical scrolling on Haiku.

I made a small change to the BTextView to prevent a 0 width or 0 height text rect and re-ran the program above and here's what I got:

before SetText()

BRect(l:4.0, t:4.0, r:1361.0, b:-4.0)
BRect(l:4.0, t:36.0, r:1361.0, b:28.0)
BRect(l:4.0, t:68.0, r:1361.0, b:60.0)

after SetText()

BRect(l:3.0, t:0.0, r:193.0, b:18.0)
BRect(l:3.0, t:0.0, r:193.0, b:18.0)
BRect(l:3.0, t:0.0, r:193.0, b:18.0)

Progress! I'll get into the change I made in a minute. The output is not exactly the same as BeOS, but it's close. It seems that BeOS will set the text rect to the width of the string, while in Haiku we set it to the width of the text view instead. That difference aside, once the text rect is not initially 0 width, the BTextView size is fixed up properly and displays correctly!

Here is the fix that I made https://review.haiku-os.org/c/haiku/+/3413 which is to add the following code to AttachedToWindow():

	// text rect right must be greater than left
	if (fTextRect.right <= fTextRect.left)
		fTextRect.right = fTextRect.left + 1;
	// text rect bottom must be greater than top
	if (fTextRect.bottom <= fTextRect.top)
		fTextRect.bottom = fTextRect.top + 1;

I hope this explanation is helpful to understanding what is going on in BTextView.

Last edited 3 years ago by jscipione (previous) (diff)

comment:7 by pulkomandy, 3 years ago

Resolution: fixed
Status: reopenedclosed

comment:8 by diver, 3 years ago

Resolution: fixed
Status: closedreopened

In hrev54738 The behaviour is different now but the bug is still valid.

Last edited 3 years ago by diver (previous) (diff)

by diver, 3 years ago

Attachment: tracker.png added

comment:9 by jscipione, 3 years ago

I have also verified that this bug is still valid, and I’ve previously created a fix for it in https://review.haiku-os.org/c/haiku/+/3399. There was another related bug that got fixed in hrev54736 which came out of the discussion from the patch. Sorry for the confusion here.

Last edited 3 years ago by jscipione (previous) (diff)

comment:10 by pulkomandy, 3 years ago

Sorry, my faut for closing the ticket too early when the commit message only said "helps with".

I am wondering if this is related in some way to #4094 or caused by it?

Last edited 3 years ago by pulkomandy (previous) (diff)

in reply to:  10 comment:11 by jscipione, 3 years ago

Replying to pulkomandy:

I am wondering if this is related in some way to #4094 or caused by it?

This seems unrelated but I’ll look into it. #4094 is probably a bug in Tracker somewhere nearby.

comment:12 by humdinger, 3 years ago

Blocking: 16799 added

comment:14 by jscipione, 3 years ago

After SetText() with text rect width set to the width of the text:

BRect(l:3.0, t:0.0, r:116.0, b:15.0)
BRect(l:3.0, t:0.0, r:170.0, b:15.0)
BRect(l:3.0, t:0.0, r:150.0, b:15.0)

comment:15 by bruno, 3 years ago

Haiku 64 bit nightly 55114 is working:

http://0x0.st/-2wA.png

comment:16 by bruno, 3 years ago

Haiku 32 bit nightly is working too! As Jscipione says, he found some related bugs and works on them, mainly to test and found in StyleEdit by margins and formatting the text there, too.

See: https://discuss.haiku-os.org/t/more-frequent-releases/10749/77?u=brunobastardi

comment:17 by pulkomandy, 3 years ago

Resolution: fixed
Status: reopenedclosed

Path has been merged in hrev55178.

Note: See TracTickets for help on using tickets.