When entered, the keyboard is grabbed when the selection becomes non-empty, and
ungrabbed if it becomes empty again or the region is left or the user switches
out of internal mode.
This fixes scroll in internal mode and note moving with arrow keys. Also frees
up useful keybindings when there is no note selection, which is much nicer than
the "nothing works in edit mode at all" greedy grab approach used previously.
Attempt #874327892 of getting this damned grabbing right.
Also push the increasingly unwieldly paste parameters into a context object.
As with othe things, currently it is only possible to do "cross-type paste" by
explicitly selecting the target track. We will need to get automation region
view selection working to do better here, but at least for now it's possible to
get the data over.
For some reason, grabbing the magic keyboard focus makes scroll stop working
regardless of what MRV::canvas_group_event() returns. I can't figure out any
reason to grab the keyboard in this case anyway, so I just removed it.
Also simlify MRV event handling code in general.
This lets us get a more explicit handle on time conversions, and is the main
step towards using actual beat:tick time and getting away from floating point
precision problems.
No functional changes in this one (for easier auditing), but towards having
round up/down only if necessary modes, rather than kludging around that
situation with a double round as we do currently.
The idea here is that pasting several times to the same location doesn't make
sense. Instead, the paste is appended past the last paste, snapped to the
grid. This make it simple to replicate a given section a number of times,
simply by copying once and pasting several times.
This behaviour only appears when successive pastes are done to the same
location (whatever the edit point is). When the paste point changes, the
"multi-paste" state is reset.
Boots 'n cats 'n boots 'n cats.
This makes for extremely confusing behaviour, particularly when creating new
regions. This is still probably too transparent, IMO, but at least isn't
totally mysterious. "visible" is a bit of a misnomer in the code, now.
Fixes crash/assert with negative Beats.
TODO discuss alternative:
automatically extend/trim region (if possible) or
accept but hide notes that are out of bounds. That would need
some solution for ghost notes which still can have negative Beats
while dragging.
Problem: mouse-scrolling over a MIDI region in internal edit mode
never released “magic widget focus” (mod keys and global scrolls after
that were ignored). -> added to leave_notify.
Also, the MouseModeChanged signal needs to be emitted when internal edit,
mode changes in order to trigger MidiRegionView::mouse_mode_changed(),
which in turn releases the magic focus while still hovering over a MIDI
region.
Remove Canvas::Layout, use Canvas::Container for the same purpose, move child-rendering into Item::render_children() so that it
could theoretically be used by any derived type.
Delivery of fake motion events to the editor needed the event coordinates to be
in canvas space, as they are with "real" events. Editor and other objects had
many redundant groups from timbyr's work on gnomecanvas to scroll by moving
groups. We don't need this anymore with cairo-canvas (though possibly a
stationay background group for the canvas might be useful again one day as in
the SAE logo. Its implementation would be fairly different though, since we
would have to explicitly move the group on every scroll, since nothing else
ever moves on scroll).
Also tweaks to text item placement, and switch TimeAxisViewItem from
name_pixbuf to name_text, since ArdourCanvas::Text is already "pixbuf optimized".
