This fixes an issues where Ardour never completes to flush the GUI event
queue due to rapid updates for meters and similar events.
ARDOUR_UI::load_session() never returned and the complete session
ran inside Gtkmm2ext::UI::flush_pending(), this later causes a crash
at exit.
as side effect, this also speeds up session load.
Routes which are busses don't have a track, and thus no playlists either:
avoid a crash when inserting time when a bus is selected and 'all
playlists' is chosen.
'Cut time' implies that the cut timeline items might end up on the
clipboard to be pasted somewhere: this isn't the case at present, so rename
the functions, class, &c. to say 'remove' rather than 'cut'.
Rename insert_time_dialog.{cc|h} to insert_remove_time_dialog while we're
at it.
Add options to move glued & locked markers to Editor::cut_time(), in line
with the insert_time() implementation.
Fix up the order in which operations apply to range marker start & end
points, to avoid problems when a range which lies after the cut point is
shorter than the length of the cut.
When inserting time and moving a range marker, move its end first, before
moving its start, so that if the time being inserted is greater than the
length of the range, we don't try to set its start to after its end.
- also allow moving of automation lines in internal mouse mode.
- this is also a first pass at ensuring that if an operation does
nothing, avoid an undo entry.
Copy the 'Cut time' code from Mixbus, making a few obvious fixes to work in
A3 (e.g. nframes_t => framepos_t / framecnt_t).
Seems to work to move & remove markers, tempo & meter markers, and regions on
selected tracks.
Still TODO:
- use existing A3 'Insert time' dialogue
- make it respect 'No selection = all tracks'
- rename the command to something like 'Remove time' or 'Delete time': 'Cut'
sounds to me as if the removed range should end up on the clipboard ready
to be pasted somewhere, which of course it doesn't.
The user can now replay *all* earlier selection operations until the next
session undo/redo command, or the completion of a new operation.
Nothing relating to selection ops is stored, and selection operation history
is begun on first idle.
Selection operation history is fundamentally different from the history of
operations which act on a selection in terms of both their viewport and the
amount of information required to replay them.
WRT undo, the user of a selection op doesn't care about the viewport state
at the beginning of an op, but rather that at the end of the previous one.
This is a somewhat wacky workaround but no there is
no better solution in sight.
Related bug:
select range, save, quit, restart & re-load session
-> range selected but tool == object