* Add group-tab sized spacer above master bus
* disable vertical scrolling (hide, show scrollbar otherwise
adds a scrollbar
* shrink main content. Do not vertically expand mixer
When adding a new route using "Front", its presentation info
order is set to 1, after the master-bus which has PI order 0.
(see Session::ensure_route_presentation_info_gap).
Mixer_UI::add_stripables, looks up the insert iterator:
"after the route with order 0", but since the master bus is
not in mixer's track-model, the insert-iterator is left "at end".
A later call to `sync_presentation_info_from_treeview` then updated
the new track's order key to be at the end.
This fixes an issue where brining up a menu can directly activate an
action in the menu. Notably on macOS.
Nathan reports that this may also address #9515
Note: mac touchpads are not affected since right-click there is
effectively a "press and hold".
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.
Since momentary override is a singleton, it needs to remain
GUI only, and not a session API available to any UI.
The middle-clicked button is rendered as pressed. So it is
already obvious and the Changed() signal that is emitted
when temporarily restoring a scene can simply be ignored.
PresentationInfo::Change (Properties::selected) is emitted and
handled before Mixer_UI::add_routes() is called. At that point
in time the MixerStrip(s) to be selected may not exist.
Visual selection state was lost.
Furthermore move_stripable_into_view() calling translate_coordinates()
only works after GTK has completed the resize operation.
This lead to the mixer scrolling back to the left edge when creating
new tracks.
Also each selection change caused all tracks to be re-packed.
Now redisplay_track_list() is only called if visibility or order
changes. This signficanly improves performance with large sessions.
