This also adds interaction with sections in the
Arrangement Ruler.
Note that selecting a range switches to the Range tool.
This is enforced because time-range selection is only meaningful
with tools that perform edit operations on the whole timeline.
Create a marker by ctrl-click, hover over it and then ctrl+z
undo. This used to crash in Editor::get_preferred_edit_position()
gtk2_ardour/editor.cc:5179, checking for entered_marker->position()
Previously CD-markers and Arrangement-markers were shown
in the default Maker ruler when CD or Arrangement ruler
were hidden.
This also fixes a bug that could result in marker-labels
being cut short. Editor::update_marker_labels calculates
overlap with other markes in the same group; but re-parenting
did not update the sorted_marker_lists[group] index.
Old code just redrew them at the same timeline position (which may
or may not be a different pixel position). They need to be updated
with the underlying position of the marker they represent
Deleting _track_canvas_viewport automatically destroys
any child Items. The LocationMarker's group was already destroyed
when ~ArdourMarker() runs and calls `delete group`.
So first delete the marker, then the canvas
This is mostly a simple lexical search+replace but the absence of operator< for
std::weak_ptr<T> leads to some complications, particularly with Evoral::Sequence
and ExportPortChannel.
Tempo Map updates can change a region's position/length, in which case
region-automation may follow the region, and DiskReader:: playlist_ranges_moved
will save additional undo information.
These MementoCommand(s) need to be included in the undo operation.
The class now has two separate methods for setting a duration or a point
value. They MUST be used appropriately, because their behavior is different.
When ::set_duration() is used in timecode mode, an extent (inclusive-end
length) is shown rather than a length.
Some objects, such as the TimeInfoBox, now deliberately shown an inclusive end
for their "end" clock, but this not universally followed, pending more feedback
from users and investigating of conventions in other DAWs.
Locations::ripple() skips these markers when the ripple action is committed.
...but the editor moves the marker-items as a visual aid, before actually
committing the changes to Locations()
...so the editor needs the same logic, to avoid visually inconsistent behavior
This commit leaves two issues outstanding:
1. unclear/ugly semantics for drag operations that reset the GUI thread's tempo map to the writable copy
2. undo/redo for the tempo map
These will be addressed in future commits
