[Tracker] desktop icons selection is shifted 1px to the left

[diver]

To see it open Magnify resize it a little bit and select Haiku volume on desktop. I will attach screenshot. Don't know ehich component to select for this bug, so please assign it.

[jackburton]

How does it look on R5 ?

[diver]

It's not shifted.

[stippi]

No it is shifted on R5, but not as much as on Haiku. I vote for changing whatever we need to change so it is indeed not shifted at all.

[jackburton]

Replying to stippi:

No it is shifted on R5, but not as much as on Haiku. I vote for changing whatever we need to change so it is indeed not shifted at all.

Of course, I didn't mean: "if it's shifted on R5, let's keep it shifted", I was just looking for an hint for where to look: i.e. Tracker or our libbe :)

[jackburton]

I suspect haiku renders the text 1 pixels off to the right in respect to how it's rendered on beos. Evidences:

• The problem described here
• this comment in BTextView::PointAt()

convert from text rect coordinates NOTE: I didn't understand why "- 1.0" and it works only correct without it on Haiku app_server. Feel free to enlighten me though! result.x += fTextRect.left; - 1.0;

• The fact that our Terminal on BeOS draws the text 1 pixel shifted to the left

[jackburton]

I had a look at this. Removing the + 1 in the following code:

BPoint loc; loc.y = textRect.bottom - view->FontInfo().descent; loc.x = textRect.left + 1;

in TextWidget.cpp, BTextWidget::Draw(), fixes the problem. But again, since the selection isn't as shifted in beos as it is on haiku, I think the problem could be more what I wrote in comment 6.

[diver]

Still here in hrev35569.

[x-ist]

Don't know if it helps but this does not happen when "List view" mode is chosen.

[diver]

As it seems to be a bug in BTextView, maybe zooey could have a look? :-)

[jackburton]

Replying to diver:

As it seems to be a bug in BTextView, maybe zooey could have a look? :-)

It's not. Tracker uses BTextView only in edit mode, not for just displaying the text.

[diver]

Damn it! :-) Anyway it's still reproducible in hrev38300.

[stippi]

I've looked into it and this is now a won't-fix for me. See hrev46903.