Regular .h files *should* be self-contained and independent of previous
includes and guarded to only include once. Make it clear which files
that *doesn't* apply for at all.
we allow use of/dependency on sigc::trackable there, so this is
both legal but also sensible.
Leave the macro definition of invalidator(x) in gtkmm2ext/gui_thread.h
because it doesn't hurt and makes some sense for it to be there. No
reason for a source module that needs invalidator(x) to load EventLoop
decl.
Previously it was possible to just press "Esc" which closes the
dialog with Gtk::RESPONSE_DELETE_EVENT and Ardour continues
to run (and may or may not crash later).
There is no need to preallocate request buffers for these threads - the event
loops that require them can allocate them when they discover and register the
pre-registered threads. This also means that event loops do not need to
register request buffer factories.
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)
