This should really be split in separate semantics for key and button events.
Fixes a subtle but nasty bug in the EngineDialog where the change of the default focus
widget from a Gtk::Button (acts on press) to an ArdourButton (acts on release) caused
events occuring after a dialog has grabbed focus to trigger button clicks
When there's no main window (initial setup, no transient parent),
preset a normal window listed in the task-bar.
The duality the Engine Dialog being used as Ardour-WM managed non-modal
Window (Menu > A/M Setup) and modal Dialog (AudioEngineSetupRequired)
complicates this a bit.
OK -> start_engine() can eg. trigger an interactive plugin scan,
which in turn leaves the EngineDialog responsive. changing settings
or clicking OK again can lead to undefined behavior.
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 replaces using ARDOUR_UI::disconnect_from_session which is only used by the
EngineControl class. ARDOUR_UI::disconnect_from_session also disconnects from
the AudioEngine::Halted signal which seems unnecessary as Halted is not emitted
when stopping the engine and calling update_sample_rate() which is already
handled when the AudioEngine::Stopped signal is emitted.
This has to be handled in two places, in ARDOUR_UI::do_audio_midi_setup and in
the dialogs response handler and in as the window can also be triggered via the
window action manager.
Use a single function with the complete logic.
Since the callgraph is complex, there is internal state as well as GUI
state (different pages), do not rely on individual methods to get it
right.
A widget's sensitivity should only be controlled by one function.
This can happen if both input and output devices are set to None for instance
on backends that report no supported SR or buffer size for the None device.
EngineControl::set_driver_popdown_strings is now like the other
set_*_popdown_strings methods in that it sets the driver strings and a
default active entry and returns false if no drivers are available.
The fix does not work properly anymore for the Portaudio backend and needs
fixing in another manner. It will now be temporarily back to the broken state
it was in before the "fix".
This stops a whole lot of redundant signal emission and makes it much easier to
think about what is going on. It also makes the dialog present much faster.
AudioBackend::enumerate_drivers is not supposed to be called for backends that
don't support driver selection. The wavesaudio backend asserts if the method is
called.
Connect to the backend_combo changed signal after setting state as calling
backend_combo.set_active_text() in set_state was triggering backend_changed(),
which would then see the driver_combo had not been set and set it to the
incorrect value.
The value/name of the backend needs to be restored first then we can populate
the driver combo and set the correct active entry from the saved state. After
which backend_changed() will populate the device combo's etc so they can then
be set to the correct active values from the saved state.
Some refactoring was necessary to avoid code duplication
Restoring of device state for input and output devices still doesn't work
correctly. I'm not quite sure what the issue is at this stage.
For some reason we don't understand 'push_state_to_backend()' can interfere with hiding the dialog (causing a partially hidden dialog to remain on screen). It's most likely a timing issue with the Windows version of GTK. Fortunately, reversing the calling order seems to fix it - BUT...
If there's no session loaded yet, the user can be left with a very long wait while nothing seems to be happening. The next thing the user would normally see would be the splash image. So let's display it slightly early (so the user can at least see that something's happening).
Sadly, it's all very kludgy - but a lot better than what we had before... :)
