Tracker scrollbar confusion

[jonas.kirilla]

Tracker's scrollbars don't seem to work right, at least in icon mode.

See attached zip files with screenshot series.

Perhaps it's related to the issue with the view contents getting moved, sort of flickering out of place, when resizing Tracker windows. Something with Tracker's idea of size/location of the content area, (or whatever it's called in the Tracker source)? I'm just guessing, so this may be all wrong.

[jonas.kirilla]

Also on R5. Both screenshot series are with the current Haiku version of Tracker.

[aldeck]

Seems related to #361, i'll have a look.

[aldeck]

hrev25896 might have fixed it. Can you check again?

[stippi]

I still have one problem, it should be easily reproducible with a fresh install: Open the folder /boot/beos/apps and switch it to icon mode (I used size 32). Cleanup the icons and resize the window to fit using the decor zoom button. The window should now enclose all icons and the scrollbars should be "off". Close the window. The state /should/ be saved. Open the window again, you should see that the contents are scrolled to one direction. If you move the scrollbar to scroll all the way there, the original state can be restored. No matter how many times you close and re-open the window, the initial unnecessary scroll offset can be observed. But it continues: If you manually try to drag all the icons by the scroll offset, you will see that re-opening the window has now a different scroll offset, unless you dragged them just right. This hints in the direction that the "absolute" icon locations directly influence the initial confusion. In other words, there is an internal coordinate space, which can be out of sync with the visible content arrangement, or at least is not correctly restored, in which case it wouldn't matter. Tracker could use internal icon locations as it likes, as long as it is able to restore the visual arrangement correctly. Two windows could enclose two piles of icons without need for scrolling (scrollbars off), while the top left location of the pile in one window could have an (internal) negative location, while the pile in the other window could use a large positive offset. However, these offsets seem to affect the initial scrolling of the windows when they are opened, while they shouldn't, or at least should restore correctly.

[axeld]

Note that this behaviour also happens under BeOS R5, but I'm pretty sure it has been introduced with OpenTracker at some point, ie. it did not happen in the original BeOS Tracker.

[aldeck]

Replying to stippi: I think there is another problem, but i've found what is the cause of the unnecessary negative offset. The icons are positioned correctly but the extent calculation is not optimal. This happens when the text of a leftmost icon is larger than the width of the icon (see Pose::CalcRect() ). In Extent() you can see that it enlarge the extent by fOffset, which would be ok if extent was enclosing icons not icons+text. I have a patch pending that fixes this by calculating two extents, one with text, one without, and a separate minimal textOffset (ex: 5px) for text that is enforced if necessary. Now the layout is nice on the first time except if an icon's text is really long.

[aldeck]

Moved the offset issue in #2372. Can we close this one?

[aldeck]

I re-checked the screenshots in the attached BugTour2.0.zip and ScrollRelatedTrackerBugsOnR5.zip.

The icon moving problem showed in shots 01 to 11 was fixed in hrev25896, it is almost certainly fixed on R5 too.

The resize to fit problem showed in shot 13 was fixed by hrev26043, should be ok on R5 too.

Can someone test on R5 please? so we can be sure. (or if someone can compile it for me, i'll do the tests)

[aldeck]

Closing this one, this is a multi-issue ticket and all seem to have been fixed. Please open a new more specific ticket (and check existing ones off-course) if there's a remaining issue.