Bugzilla – Bug 487
Scrollbars behaviour is inconsistent when project fits in window
Last modified: 2019-05-26 08:00:16 UTC
When the project is made to fit to window, either vertically, horizontally or both, sometimes there are scrollbars and sometimes not.
On Win and Ubuntu 10.10 I always get a scrollbar when vertically or horizontally fitted. But on Ubuntu when importing a single mono file there is no vertical scrollbar; when that single file is fitted vertically, so increasing the height of the track, a vertical scrollbar appears. On Win the vertical scrollbar is there even on import of the file because there are always scrollbars, even in an empty project. The only question I see is, should there be a scrollbar at all where there is nothing to scroll? But since we allow scrollable space at the end of a horizontally fitted track, it seems valid there should always be a horizontal scrollbar, which I do see. Don't you?
(In reply to comment #1) On Mac 2.0.0, on fit vertically sometimes a vertical scrollbar appears and sometimes not. Mostly not. I don't see this as a big deal. On fit horizontally a scrollbar always appears and I agree this is correct, so that the user can scroll past the end of the longest track in the project.
(In reply to comment #2) On Debian Squeeze I usually get both horizontal and vertical scrollbars but there are inconsistencies. Example: New Project (non-maximised window) Generate tone 30 s duration. * There is a horizontal scrollbar. * The track fits in the window vertically and there is no vertical scrollbar. Ctrl+shift+F * The track expands vertically to almost fill the Track Panel window. * There is a horizontal scrollbar * There is a vertical scrollbar. * The track CANNOT be scrolled vertically Ctrl+3 * The track zooms out horizontally * There is no horizontal scrollbar * There is a vertical scrollbar. Ctrl+3 (again) * The track zooms out horizontally * There is no horizontal scrollbar * There is NO vertical scrollbar. Ctrl+1 * The track zooms back in horizontally * There is no horizontal scrollbar * There is still NO vertical scrollbar. Ctrl+1 (again) * The track zooms back in horizontally * There is no horizontal scrollbar * There is still NO vertical scrollbar. Ctrl+1 (again) * The track zooms back in horizontally * There is no horizontal scrollbar * There IS a vertical scrollbar. After the initial Ctrl+shift+F there has been no resizing vertically, so the vertical scrollbar should not be appearing and disappearing. > I don't see this as a big deal. Hence marked P5. > should there be a scrollbar at all where there is > nothing to scroll? I've changed my mind 3 times while considering that question. > But since we allow scrollable space at the end of a > horizontally fitted track... Yes it is definitely useful to be able to scroll into the white space beyond the end of the tracks. It would probably be more useful if there was no restriction on how far one could scroll. Currently, with a 30 second audio track that has been "Zoomed to Fit" horizontally it is possible to scroll so that about 7.5 seconds of white space can be seen, but the selection can extend as far as the screen will allow the mouse to move. The amount of white space that can be scrolled into appears to be about 25% of the project length. I can think of several situations where it would be useful to be able to scroll further (without needing to zoom out). This is moving into an "enhancement" but I think that a better behaviour would be if scrolling or selecting further to the right caused the "sliding bar" of the scrollbar to progressively shrink so as to indicate the proportion of on-screen space in relation to the duration from t=0.
A regular 'RepeatableAll' P5 bug, not 'Review'.
I have not observed this on Windows or Mac for as long as I can remener. I did extensive testing with a) 2.3.3 alpha on W10 b) 2.3.2 on macOS 10.15.5 and I cannot induce this errant behavior
