Context menus should (unless there is a very strong reason otherwise) be
popped up on button press, not button release. In addition Gtk::Menu::popup()
should be given the button ID of the button used, so that it can manage
both styles of menu interaction (press/drag/release and press/release/drag/press)
They already worked in the PianorollMidiView, because that hands off enter/leave events
to the parent EditingContext (a Pianoroll). But MidiRegionView and Editor were
not interacting in the same way, so leaving a note object would not cause the Editor
to do the right thing with the cursor.
Unclear why I use this pattern when the change here uses the more normal way
of finding the upper/lower of some values. Either way, the code as it was would
skip the first event in a MIDI trigger (most of the time, anyway)
There's an assumption that slots with regions cannot be recorded into,
so adding a region to an empty slot makes it impossible to record to that
slot.
Create the region at the appropriate point during a NoteCreateDrag.
This may also be needed for some automation drawing drag operations.
As noted in 8b389ee829, we now clear the _note_group container
before any other Note items might be deleted. But since this
may delete the _ghost_note, we have to be sure to reset
that to a null ptr to avoid a double-free later during
~MidiView
Following the introduction of 'Pianoroll::region_prop_change()' (commit #29833d75c9) the operator<< (for PBD::PropertyChange) now needs to be visible outside of libpbd
Previously this worked since rulers were initialized first, setting
the videtimeline's height. After the ruler overhaul the
videotl_bar_height was not set until after the ruler
is shown. This lead to requesting some insanely large video frame...
We now use a stack allocator when making a copy of current connection state at
the start of the signal emission process, and when collecting results from
signal handlers in the case of a non-void return type.
These changes also include a functionally neutral reworking of how the connection
state copy is made and then used to check that a connection/handler is still
valid mid-emission.
Heap allocation will still happen if a signal has more than (currently) 512
connections. A little experimentation reveals that the maximum number of
connections is typically nroutes+1, so 512 seems like a reasonable choice
for this.
~LocationMarkers() emits CatchDeletion, which calls
Selection::remove(ArdourMarker*) which in turn calls
Editor::marker_selection_changed(), which can cause a
heap-use-after-free.
So we first need to clear the location_markers map,
before deleting the markers.
