[Tracker] text rect is off while renaming desktop icons

[diver]

Possibly related to hrev54496.

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

[jscipione]

Reverted in hrev54530/hrev54531. Fixed again in hrev54549.

[diver]

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

[jscipione]

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.

[X512]

Similar problem in BTextControl. It worked fine before hrev54549.

[jscipione]

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.

[diver]

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

[jscipione]

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.

[pulkomandy]

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?

[jscipione]

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.

[bitigchi]

​https://review.haiku-os.org/c/haiku/+/3642

[jscipione]

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)

[bruno]

Haiku 64 bit nightly 55114 is working:

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

[bruno]

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

[pulkomandy]

Path has been merged in hrev55178.