1. Alt is still handled to change drag behavior
2. Selection doesn't store notes unless they are part of the cut buffer, which means we should not
be altering the note selection in the editor's selection object most of the time.
1) Notes are only present in a Selection object if it is being used as a cut buffer. They are never stored
there as part of "normal selection" - that is delegated/left to MidiRegionViews that own the notes.
2) MidiRegionViews are stored in the Selection as "just" RegionViews, so provide a convenience
method to access them. This doesn't actually change much, since even the old MidiRegions object
was actually just a RegionSelection i.e. RegionViews.
We now check from the focus widget (if any) for any widget heirarchy bindings, and try to use them.
Next use the "top level" bindings passed in (top level is quoted because they may be owned by a tab,
rather than a window).
Finally, if the event is still not handled, try the global bindings
This model more closely matches what I think a reasonable programmer with experience of other
GUI toolkits would expect, and allows us to have multiple bindings present (though not
simultaneously used) in a given window
This allows "stacking" of bindings by desensitizing the actions associated with a "lower" level
of bindings at certain times (e.g. MIDI editing bindings thare are sensitized in the appropriate
editing modes
Two main problems are addressed by this commit.
First, storage of
parameters was broken because the index for values was set by the
parameter count, not the control port count which set_processor_param()
expects.
Second, the value was not clamped to pd.upper and pd.lower causing some
parameters to fail when set.
This invalidates previous mixer store files.
As soon as we ripple drag the selected region out of the original track,
::remove_unselected_from_views() is called and the rippled regions on the
original track are not covered when ::remove_selected_from_views() is called
again in ::finished(). Therefore we need to shift the regions remaining on the
original track back and forth again, in order to have them properly in the undo
history.
Previously only drag/drop to existing tracks used the target
time-position and files imported as new tracks using the drop-zone
were placed at 00:00:00:00.
This also fixes a logic error when "get_only_copy_imported_files"
was unset.
The condition under which "copy" was mandatory was rather convoluted,
so this also provides a more consistent user-experience.
Man new users drag/drop files onto the canvas without being aware
that Ardour only references external files. This can break sessions
when those files [re]moved.
