After the editor is attached as tab to the main window,
looking up keyboard bindings using get_toplevel() no longer
works.
This uses the widget-hierarchy just like ARDOUR_UI does.
When limiting the message count (e.g. for display in a dialog),
use reverse order, and only print errors.
When loading a session fails, the most recent error is
more likely the real cause.
This adds the time when a log message is displayed.
ARDOUR_UI::display_message() parses the prefix,
so the timestamp cannot be prefixed in the beforehand.
Still, UI::process_error_message() is called directly in
the same thread, so this makes no significant difference.
Changing a tooltip resets the timeout. In one particular case,
while rolling, AudioClock::set() is calling set_tooltip() at a rate
faster than the tooltip timeout and prevents tooltip from showing at all
(even if there is no actual change to the tooltip text).
Alas, there is no trivial fix for this UI side and there may be other
such cases. A central check is more than practical.
In some circumstances UI::flush_pending never returns, and all UI
interactive ends up being driven by
while (gtk_events_pending()) { gtk_main_iteration(); }
This has various implications depending on the caller and usually results
in a crash at session-close or exit.
This new design will work even when threads that need to receive
messages from RT threads are created *after* the RT threads. The
existing design would fail because the RT thread(s) would never
be known the later created threads, and so signals emitted by the
RT thread and causing call_slot() in the receiver would end up
being enqueued using a lock-protected list. The new design ensures
that communication always uses a lock-free FIFO instead
This cleans up a lot of false-positives in static analysis
and also helps compilers to optimize code paths in general.
(tagging the fatal stingstream operator as ‘noreturn’ is
far less trivial)
Using a timeout source to process ui events/requests is suboptimal
but it works for the moment. Have to use g_source functions as glibmm
functions are not thread safe AFAIK.
Behaviour should be exactly the same on unix.
