The function builds pop up menus that are never displayed and
creates runtime debug warnings. It is left over from PRL's experiment
in 2.1.2 with a context menu for the vertical ruler.
... See comments #1 and #2 at
http://bugzilla.audacityteam.org/show_bug.cgi?id=1331
Don't make strange undo history if, e.g., R to record (or other keystroke
with undoable effects) interrupts a drag with undoable effects (like time
shift). Ensure that by first simulating a mouse button up event to stop the
drag, before dispatching the keystroke.
Don't crash if certain other drags, that do not have undoable effects, such
as selection or vertical ruler drag -- are interrupted by a keystroke
command (Ctrl+C in particular could cause crash). However, in these cases,
the drag is still allowed to continue.
... This affects those keys (and NUMPAD arrows), also (shift-)ctrl-f6,
ctrl-home, ctrl-end (which are command-left and right on mac)
Those should be tested to ensure correct restoration of the yellow rectangle,
appropriately in the tracks or the ruler.
This should also be tested with and without the Tracks preference for cyclic
movement of the focus.
... The explanation was not, as I had thought, that mouse capture is simply
broken in wxWidgets 3.0.2 for Mac.
Instead, it now appears that Leaving mouse events always falsely report no
buttons are down, which confused our code.
... activated by clicking near the left end of the ruler, then using the
context menu.
This is not finished work, but a proof of concept for a possible new scrubbing
UI.
... if the event is not handled and skipped by sub-windows first, such as for
toolbar button clicks.
(But track panel clicks are skipped even after doing something, so they may
also cause seeking besides other responses. So click can seek AND set cursor.)
This is meant to make drag to seek and wheel for change of speed easier,
without needing to keep the mouse in the narrow time ruler.
Also lets you click in the ruler, then move in any direction, and not miss the
motion event that should start the scrub playback.
The event handling is a bit of a hack, using propagation. It does not use
capture.
... and works in any of the six tools.
Click and drag in select tool during scrub works just as when not scrubbing.
Seeks now only if you left-click or drag in the ruler, but this may change.
Mouse motion anywhere on the screen controls scrub as before.
No mouse clicks in TrackPanel are used by scrubbing.
The Ctrl-Click in TrackPanel is now unused. Should 2.1.0 behavior be restored?
That was click to quick play, redundant with click in the (lower part of) the
ruler.
... This includes new always-seeking modes unlike scrubbing which can switch
to seeking and back according to the left mouse button state.
The reason for this is that visually impaired users should not be required to
click with the mouse in the track panel window to signal seeking. But mouse
movements can still control scrubbing, because we poll the global mouse
position in the timer, not relying on events from any window object.
... So it does not depend on the focused window, and can work when selection
toolbar has focus. But TrackPanel's escape handling may still take precedence
over it.
... If there is play but also an escapable drag action in TrackPanel, such as
a change of selection, then ESC aborts the drag. A second ESC would stop play.
The event handling for these ESC actions may be in the wrong place though. If
you ctrl-f6 during play so that the selection toolbar gets focus, then ESC
does not work to stop play.
