Previously (since bc91ea3c4) that would create a new session
even if -N was not specified.
This also uses Glib API to test for absolute path, rather
than a custom hack.
Without this, loading a session from the command line bypasses any initialization of session_loaded
and after the changes in 0a72c1317 that leads to incorrect startup
* add spaces around "->"
* consistently use "time domain" (instead of "timebase")
* remove "Edit ->" from "Preferences" (on macOS Prefs
are not in the edit menu
Previously [GtkApplicationDelegate applicationShouldTerminate:]
triggered both StartupFSM::queue_finish and ArdourUI::queue_finish.
Both of which registered an idle-callback to call ArdourUI::finish.
In some startup flows, the entire loading process happens inside
StartupFSM::start(). In others, that call gets things moving but
we return from it and loading is not complete until later.
Deleting the StartupFSM while still inside the ::start() call
led to a use-after-free error. This new code will leak the StartupFSM
in some startup flows.
The old state in this commit would lead to an existing session
being loaded with the claim that it was a new session. This went
unnoticed until 4bed642d71, where newness impacted the time
domain of the session (and actually led to it being set to a random memory
value).
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.
StartupFSM does not catch SessionException from Session::load_state,
but bails out early, after checking `get_info_from_path` instead.
So we have to explicitly report errors.
This allows new user to select the soundcard and I/O settings
when loading demo sessions at first run, or when tricking Ardour
to open an existing session (try to create an existing session,
user may choose to load it instead).
Normally a user can only create a new session after first running
Ardour, and creating new sessions always shows the dialog (to
set the samplerate).
The ShouldLoad() signal is handled by flush_pending(). This is the first
time that normal application flow can be interrupted in ::starting()
after app->ready().
This calls ::load_from_application_api(), which in turn calls
startup_fsm->handle_path(). This sets off the complete initalization
process, loading the session, and concludes with ::sfsm_response(),
where there is a call to `delete startup_fsm;`
Previously execution continued in StartupFSM::start() which caused a
crash.
This currently only handles initial session load by dbl-click on
a session file. It also does not work if the user or new or
subject to a pre-release warning. These last two restrictions
may remain in place, although if a person's first exposure to
the program is "copy my session, download program, dbl-click
on the session file", then that's not so nice
