0006721: Mouse wheel in ruler area causes zoom instead of scroll - MantisBT

ID	Project	Category	View Status	Date Submitted	Last Update

0006721	ardour	bugs	public	2016-01-03 01:18	2016-01-03 02:18

Reporter	don3	Assigned To
Priority	normal	Severity	minor	Reproducibility	always
Status	new	Resolution	open
Platform	Linux	OS	Fedora	OS Version	21 + CCRMA
Product Version	4.4

Summary	0006721: Mouse wheel in ruler area causes zoom instead of scroll
Description	Follow-on to bug 0006528, which is Resolved, but only because the reporter got an explanation of what was happening. Is the behavior discussed in 0006528 a feature or a bug? Seems to me to be a bug, so I've put it in that category, but does it fit some work flow? It's almost always surprising to me (not in a good way ;) but perhaps I'm missing something..? In the ruler area, mousewheel, shift-mousewheel, and ctrl-mousewheel all seem to do the same thing: zoom. Does that make sense?
Steps To Reproduce	1: Move cursor to a track area. 2: Observe behavior of mousewheel (V-scroll), shift-mousewheel (H-scroll), ctrl-mousewheel (H-zoom). 3: Move cursor to ruler area. 4: Observe behavior of mousewheel (H-zoom), shift-mousewheel (H-zoom), ctrl-mousewheel (H-zoom). Unless there's a good reason for this, I would assume all three functions should be available in the ruler area also. V-scroll could be debatable, as the ruler never(?) contains enough stuff to scroll in that direction, but it seems reasonable (I think) to have that scroll the track area also. It would be symmetric with H-scrolling from the track header area.
Tags	No tags attached.

x42 2016-01-03 01:29 administrator ~0017761	it is an intentional feature. This allows to zoom with a mouse with a single-scroll-wheel(vertical), without using any keyboard modifiers. There has been some discussion about this without consensus so far. Options on the table: 1) vertical scroll is zoom only in the top-most ruler (time) 2) vertical scroll on all rulers zooms (current behavior in Ardour) 3) don't allow zoom with vertical-scroll without keyboard modifier (Mixbus does this, some users on the Mixbus forum would prefer option 1).

don3 2016-01-03 01:30 reporter ~0017762	Just found bug 0006292, which asserts that it's nice that mousewheel without control in the ruler area produces zoom. I can't say I agree, but there's at least 1 vote for that behavior being a "feature"... That bug also asks for shift-mousewheel to produce horizontal scrolling, so in that sense, this bug (0006721) is a dup. Apologies - I didn't see it in my initial search.

don3 2016-01-03 02:18 reporter ~0017763	x42: Thanks for the explanation. I can agree that in general an action _without_ a modifier key is easier than _with_ a modifier key -- but for me, this behavior is surprising because after a while the scroll and zoom functions become sort of "muscle memory", and I don't stop to think about which area the cursor's in. So for me consistency is more important that the saved keystroke. I usually have fingers hanging out near ctrl and shift keys when I'm doing this kind of stuff anyway, so the inconvenience / time penalty for using one of them is pretty small. If I had to choose between options 1 and 2, I'd take 1, only because it reduces the (screen) area of the inconsistency to a place my cursor's rarely in, so it reduces the probability I'll trip over it. But then I'd expect that people who like this behavior would be annoyed that they have to move the cursor into the small time area to get it to do what they want. :-) If I'm the only one that doesn't care for the current behavior, we can close this bug. Maybe I'll get used to it. (I haven't yet, but maybe I'll see the light at some point.) Or could option 4 be to make it a user preference?

Date Modified	Username	Field	Change
2016-01-03 01:18	don3	New Issue
2016-01-03 01:29	x42	Note Added: 0017761
2016-01-03 01:30	don3	Note Added: 0017762
2016-01-03 01:37	x42	Relationship added	related to 0006528
2016-01-03 01:37	x42	Relationship added	related to 0006292
2016-01-03 02:18	don3	Note Added: 0017763