Too many users report they import their first tracks and can't find them.
Previous default was "at file timestamp". If a file has no timestamp,
the import dialog shows "00:00:00:00" but in absence of a timestamp,
Editor::add_sources() first checks target tracks and adds add it after
the last region, then falls back to use preferred edit position as
insert point.
In the rare case where a file has timestamps it may show up a few hours
in the future.
conclusion: import-at-timestamp is not a good default.
* pressing Esc or WM close button did not cancel import thread
* proper Abort does not wait for import thread either
It was possible to launch a 2nd (and Nth) import thread, all sharing
the Editor's ImportStatus data-structure, all having the same
registered thread-name and same thread-pool name. Plenty of room for
crashes.
opening a recent session from a session can result in: Editor::constructed
and session_loaded() being true. A partial instant_save can occur (not
to mention: invalid XMLnode iterators)
On windows AudioRegionEditor d'tor never returns, stalling or
crashing in pthread_join() after pthread_cancel().
Crashes happen if two thread pools with the same name exist.
(but since the thread has no event loop, no pool is needed)
After showing Region Properties any operation that would close the dialog
will either cause the application to hang indefinitely or terminate.
This also consolidates code: CrossThreadChannel works on windows these days
http://tracker.ardour.org/view.php?id=6833
When searching for our keyboard bindings file, ArdourKeyboard::find_bindings_files() was trying to find files with the wrong extension:- "..keys" rather than ".keys" (note the extra period). Fortunately, some later code was masking the problem (so we were eventually finding the file correctly). However we might as well fix the problem here, just in case we ever need to call ArdourKeyboard::find_bindings_files() from somewhere else in the future.
