Methods that have been moved to EditingContext need
to reference the abstract definition there, and PublicEditor's
first parent class also need to be EditingContext (same
memory address)
We cannot switch on a leave event from a widget, because the undo/redo menu items must remain
labelled until we are actually in a new editing context. So switch when we switch tabs
or when we edit the (MIDI) cue editor
We cannot switch on a leave event from a widget, because the undo/redo menu items must remain
labelled until we are actually in a new editing context. So switch when we switch tabs
or when we edit the (MIDI) cue editor
MIDITrigger now has a direct reference to a MidiModel, and uses
that as the basis for discovering what state has changed and needs
updated after an edit operation pushes a new state to the trigger
The actions and draw_xxx values are now "static", and changes in the values are
notified via a static PBD::Signal so that each EditingContext can update the
appearance of its relevant widgets.
Note also wider use of lambdas when creating actions and menu items.
This also only uses the draw length parameter if no motion
occured during the NoteCreateDrag. Otherwise it uses the length that was
dragged (which is subjected to a threshold).
This may be the first of several instances where mixing
timeline-relative positions and global canvas coordinates leads to
problems. Let's hope there are not too many.
For the main editor, the timeline starts at the left edge of the editor
canvas. But for MidiCueEditor, we place a canvas-ified piano roll header on the
left of the canvas, so the timeline starts at some position right of that.
Note that this means that converting global canvas coordinates to timeline
coordinates is no longer guaranteed to be a 1:1 transform (it will be for
Editor, but in general for EditingContext).
