On Sunday, June 27, 2010, Ted Felix wrote: > I propose changing the playback position pointer behavior as follows:
> Drag - snap to beat > Shift-Drag - smooth drag > Ctrl-Drag - special feature: set the loop range This stuff is all deeper than it looks on the surface. I've taken a good chunk of time to piddle around and really see what I think about all of this. First, I take your point that shift+click to set the loop/range is not consistent with the meaning of shift+click in other contexts. Normally it means "remove the snap granularity restriction from the act I'm performing" and that is not the case here. Is it worth changing long-established behavior that has been documented since our very earliest documentation in order to make it more consistent with the rest of our interface? I would vote no, but that's a vote, not a proclamation. Second, the snapping business, when I really think about what's happening here in these three contexts, I don't think there's necessarily any way to do a snap in the main window segment canvas that makes sense. That is more than likely why it doesn't snap. In the matrix, moving the cursor along the ruler snaps to the current grid setting, and you control the granularity with the grid combo box. If you set the grid to "none" then it behaves exactly as in the main window. In notation, the cursor snaps to follow complex layout rules having to do with the notation elements in the vicinity, and it's highly variable and context- dependent. In the main window, there is no notation layout, nor is there any kind of grid setting, so it's the equivalent of the matrix grid being set to "none" and it's infinitely fine-grained. I can agree that the main window not snapping does not seem consistent. My first reaction to all of this was to propose that we should make the main window snap, but leave the shift+click loop thing alone. However, after deeper thought on the matter, I'm no longer so convinced that it's inconsistent at all. If the main window were going to snap, the only thing it could snap on would be whole beats relative to the time signature in effect. I suppose that *could* be done, but would it improve anything? What happens to consistency then when in the matrix with a grid of "none" and the infinitely-grained ruler that results? Where is consistency in that case? Another point is that the ruler snap granularity at the edit view level is directly tied to the <<< and >>> buttons and the Left/Right arrow keys. These work hand-in-hand together. The main window does not have <<< and >>> buttons, and the Left/Right arrow keys scroll the canvas. As such, it seems less significant that it is not possible to move the cursor in a snapping fashion in this context. There's little to be gained by clicking and dragging on the ruler in any context, and the main reason why the snap granularity is useful is because of the keyboard shortcut/buttons for moving the edit entry cursor. In both editors, it is possible to enter note events using only the keyboard, and this cursor manipulation exists as part of that system. On the main window segment canvas, however, it is not possible to create things using only the keyboard, so snap granularity seems largely irrelevant. That's my analysis after putting some serious thought into these questions. It seems to me that our current behavior is logical after all, and the only thing that really stands out is the business of shift+click being used inconsistently. Perhaps others will disagree though. Anyway, it's always interesting to take a step back and really question things you've been taking for granted for years. While I'm objecting to your proposal, I'm doing so after really looking at the trees for once, instead of the forest. -- D. Michael McIntyre ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ Rosegarden-devel mailing list [email protected] - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
