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.
This doesn't seem to have been touched for years, and I don't see how such an
obvious bug could possibly have been around for so long, but, well, this fixes
it as far as I can tell.
I am not sure what causes this, but it can happen when finishing a record
sometimes. Probably MidiSource::_writing isn't updated in the right order with
whatever triggers the redisplay, but at least not crashing is better...
For things like copying from pitch bender to a CC.
Also things like fader to pan, but that seems a bit funny. The conversion
probably needs to be a bit smarter here, perhaps taking the normal into
consideration...
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.
I attempted to preserve the "don't draw unless different" by ditching rounding for more
precise display_span, but that didn't work. An alternative solution would be
to draw on adjustment change if there's text, since then we need to redraw
regardless of slider position, but it seemed weird even just with respect to
the slider, so I opted for this, which really definitely redraws when the
adjustment changes, period.
If this proves to be a performance issue we'll have to figure that out.
Hopefully-desired behaviour is that controls created in the GUI are linear, so
clicking in stuff works like other automation, but controls that originated
from recording are set to discrete so Ardour plays back the input exactly,
instead of doing crazy things like linear interpolation of already high-rate
user input, hold pedals, and so on.
Hopefully that remains the desired behaviour, because we're basically screwed
for ever making any control discrete by default, since we only save the mode to
XML at all if it's not the default, which is currently linear.
