This is a bit arbitary but they are supposed to be invokable from anywhere, and since they control Tabbables and note
pure windows, they are not part of WM::Manager's purview (Window/* actions). Thus ... Common
The ToggleAction has a lifetime of the UI, independent of the
CheckOption widget. The CheckOption needs to unsubscribe from the
signal_toggled() signal when it is deleted.
Also a CheckOption without a Action makes no sense. require _action
to be give at instantiation time.
Add Mixer-specific view keybindings for list, vca, mon. (thanks to: the_CLA)
Move monitor keybindings (mute, dim, mono) to be globally-accessible.
Implement new mixer-specific actions to show/hide monitor,vcas,mixbuses (the_CLA)
Move monitor funcs (mute,dim,mono) to globally-accessible actions.
Make a new Monitor group insted of using Transport group.
Allow use-monitor-section to be controlled by both menu and session-options dialog.
Previously Editor::instant_save() returned if no session was loaded,
effectively Config->add_instant_xml(get_state()); was never called.
instant save() is called early on, in Editor's c'tor before the editor
is realized and saves invalid window-size and window-state, which
are used later.
under some circumstances, e.g. session-exit it is possible to to have
inconsistent information
ARDOUR_UI::instance()->session_loaded == true
&& ARDOUR_UI::instance()->the_session() == NULL
This lead to a crash on MacOS/X. stopping the engine at exit may destory
an Aggregate Device, leading to DeviceListChanged which in turn updates
the engine-dialog..
else if (ARDOUR_UI::instance()->session_loaded) {
float active_sr = ARDOUR_UI::instance()->the_session()->nominal_sample_rate ();
There are two cases:
(A) Proxy is created first, dialog is created later on demand
(B) Dialog is created and directly registers its window as proxy
In (B) the dialog is usually on the stack and destroyed when the
ArdourDialog instances leaves scope. In that case ~ArdourDialog()
is called and the proxy remained.
Destroying the proxy does destroy the registered window in ~WindowProxy()
If ArdourDialog's d'tor itself deletes the proxy it would recurse into
itself. Existing APIs e.g. drop_window() likewise delete the window and
cannot be safely called from ~ArdourDialog.
