VST preset restore has to happen in the GUI thread, specifically
the plugin's own UI event-loop (which on Linux and Windows is
not usually Ardour's Thread 1). However if there is no plugin
GUI, it should be safe to use Ardour's UI thread.
A widget's style (font) is only set after the widget has been
packed and inherits relevant information from the top-level window.
`set_size_request_to_display_given_text()` produces incorrect
results when it is called for widgets without a top-level
(here ARDOUR_UI::setup_windows() _main_window.add(), changes the
font from "Sans 11" to "Sans 9" for ArdourDropdowns).
`set_size_request_to_display_given_text()` must subscribe to
`signal_style_changed()`, however in case of ArdourButton UI-scaling
of elements also needs to be taken into account. It is preferable
to allow for multiple sizing-texts directly.
RegionFactory::create(Region&,..) copies all region properties.
There are however various operations that use a new Source
as intermediate to create a new Region from another Region.
Those operations should also inherit various region properties
(such as mute, opaque, locked, ..)
This likely broke in 3.x when Ardour migrated to context dependent
shortcuts (rather than GTK managed menu shortcuts).
While there is Gtkmm2ext::Application::hide, there is currently no
bindable action and hence no way to add a dedicated
shortcut. Furthermore, since this is a special NSApplication menu,
updating the menu-item when the action is bound is not trivial.
gtk_application_hide() is only implemented for macOS and
there is likely a better use for "H" shortcut anyway.
With name-bars the region was colored using the track color
if the region is not high enough to show the name-bar.
This happened regardless of the color-regions-using-track-color
preference IFF name-bars were enabled.
However set_color/get_fill_color() is not called when the track-height
changes "high_enough_for_name". This lead to inconsistently colored
regions, some with a background some without.
dbolton
Robin Gareus
Paul Davis