I can't see a reason to select the newly-created regions after
splitting selected regions: I can't think of any case where you'd want
the next operation to apply to both the regions, and it makes it very
easy (in my experience) to trim/move/&c. both regions afterwards by
mistake.
However, this behaviour is desired for Mixbus, so make the selection of
regions after a split of selected regions dependent on
Profile->get_mixbus() for now.
This fixes issues where button text was set during static
initialization where the widget style was not yet available,
and a lot of related issues where the text was set
before style.
However, keep the path for deletions in the editor-mixer via _entered_mixer_strip
TODO: if nothing was deleted, assume the user was trying to delete something in the editor instead
Show selected plugins by a red border
TODO: more work on the selection model for plugins and mixer strips
This had to be hacked because the editor_mixer strip is on the editor and doesnt respond to mixer keybindings.
Also force the gain intry to lose focus if the user leaves the mixer strip. this will probably solve some long-standing complaints. although perhaps a more elegant solution is possible.
This is needed to be able to lock the application fully on OS X, where the global menu bar would still allow interaction
even when a modal dialog is displayed.
Deleting regions (or ranges, or anything) shouldn't affect the contents of
the clipboard - only CutCopyOp::Copy, CutCopyOp::Cut and CutCopyOp::Clear
should do that.
Add a value for Ripple to EditMode enum.
Add Ripple edit mode to edit mode dropdown, by adding it to the
Editor::build_edit_mode_menu() helper function, and remove the old code that
added items to the (now unused) Editor::edit_mode_strings.
Add the regions that should be affected by the drag to RegionDrag::_views so
that the drag carries them along automatically.
Use a copy of the RegionList in Playlist::core_ripple(), since bad things
happen when iterating over regions and they get moved around in the list.
Handle rippling in removal of regions from playlist.
When dragging in ripple mode, exclude all regions that lie before the
original start position of the selected regions being dragged from
rippling: this is what Mixbus does.
Make editor dragging respect snap-to settings, by using the existing
compute_x_delta() function, which did almost the right thing. Move setting
of _last_frame_position out of that function so all ripple-dragged regions
can move.
Ripple when dragging from region list: even though Mixbus doesn't do this, it
seems like a good idea.
Prevent multi-track selection being dragged across tracks, by making
RegionMotionDrag::y_movement_allowed() virtual, and overriding it in
RegionRippleDrag to forbid dragging of selections containing regions on more
than one track to dofferent tracks in ripple mode.
Remember which TimeAxisView a ripple-mode drag that's allowed cross-track
drags started from, so that the effect of rippling regions after any region
that's dragged off that track can be undone.
