When right-clicking in the text entry, popup menu grabs focus. Consequently, the "focus out" handler is called, destroys the text entry and replaces it by the label name of the track.
When menu pops up, it tries to access to a widget no longer available.
This allows the clear methods to be used before calling ::add(), to avoid the
emission of a signal saying "there are no <foo> selected right now".
There should be no side-effects from this commit.
Note that correct use of this new API is complex, and requires avoiding the use
of wrapper methods like clear_objects().
It may happen that during push_state_to_backend() a device is
reconfigured in a way that triggers a "Device Changed" callback before
the engine is started. This callback can trigger a change to the
configuration that will be used when the engine is actually started.
This has been seen on OSX in conjunction with Aggregate Devices
(even if the aggregate is not used, but the device which is used
is also part of an aggregate)
example: HW changed callback arrives, device-list is re-populated,
*A*irplay" is at the top of the list, Airplay supports only 44.1K,
Samplerate changes... later save also writes this new rate to the file.
This was triggered when reloading session and immediately duplicating range with
keyboard shortcut. As clicked_selection was uninitialized it would try to use
an invalid index into the TimeSelection.
In response to a comment in #6722, as there is little delineation between the
ruler and track canvas areas it makes sense to keep the scrolling step the same
to avoid unintended jumps in scrolling if mouse cursor moves between areas.
This means that mouse zoom scrolling behaviour is consistent on the ruler
canvas area and track canvas area.
The config option defaults to true so this means the behaviour of Mixbus will
be unchanged but in Ardour the ruler area will now follow the option so by
default will use the mouse position as zoom focus when zooming rather than the
zoom focus setting.
Keep the same scrolling distance per event as when scroll left/right is used.
Scrolling in the ruler area is different than the track canvas area which I'm
not sure is a great idea as there is not much delineation between the two areas
but as the ruler area has some other different behaviour it is probably
acceptable/useful.
Keep scroll distance consistent when scrolling up and down with horizontal
modifier as when scrolling left to right.
Scroll horizonally by half a page so that no sections of the canvas are skipped
when scrolling.
Scroll by half a page rather than a step like when scrolling in the track
canvas area as it is a summary area so larger steps seem acceptable and having
it use the same scroll distance as when scrolling in the track canvas seems
pointless as you would then just scroll in the track canvas area.
Each MidiRegionView(MRV) is connected to the Selection::ClearMidiNoteSelection
signal that is used to notify the all MRV instances to clear their note
selection.
The MRV class also has a private static SelectionCleared signal that is used to
signal other MRV instances when their selection has been cleared. When the
Selection::ClearMidiNoteSelection signal is emitted it causes each MRV to also
emit the SelectionCleared signal. So the emission takes quadratic time.
With 1500 MRV instances emission takes about 2.2 seconds on my machine, and
some operations like track selection cause it to be emitted 3 times(another
issue).
The Selection class in the Editor knows which MRV instances have note
selections, as it is notified by MidiRegionView whenever the selection count
becomes zero or becomes non-zero. Clearing the Note selection should then just
be O(N) and direct calls can be used rather than signals.
This change removes both the signals and uses the existing references between
Selection and MRV class to control note selection. There should be no
behavioural changes in Midi note selection with this change.
