Opened 12 years ago

Closed 11 years ago

#1263 closed bug (fixed)

Tracker scrollbar confusion

Reported by: jonas.kirilla Owned by: axeld
Priority: normal Milestone: R1
Component: Applications/Tracker Version: R1/pre-alpha1
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All


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.

Attachments (2) (24.1 KB) - added by jonas.kirilla 12 years ago. (61.7 KB) - added by jonas.kirilla 12 years ago.
Also on R5. Both screenshot series are with the current Haiku version of Tracker.

Download all attachments as: .zip

Change History (10)

Changed 12 years ago by jonas.kirilla

Changed 12 years ago by jonas.kirilla

Attachment: added

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

comment:1 Changed 11 years ago by aldeck

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

comment:2 Changed 11 years ago by aldeck

hrev25896 might have fixed it. Can you check again?

comment:3 Changed 11 years ago by 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.

comment:4 Changed 11 years ago by 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.

comment:5 in reply to:  3 Changed 11 years ago by 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.

comment:6 Changed 11 years ago by aldeck

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

comment:7 Changed 11 years ago by aldeck

I re-checked the screenshots in the attached and

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)

comment:8 Changed 11 years ago by aldeck

Resolution: fixed
Status: newclosed

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.

Note: See TracTickets for help on using tickets.