macOS has its own z-axis stacking (see Manager::set_transient_for) for
dialog and utility windows of a single application. There only case to
set a dedicated transient parent is to keep the child window on top of a
dialog.
Valid use-cases are e.g.
Plugin Preset Name entry on top of a PluginWindow
Export Format Settings on top of the Export Dialog
Alternatively one would need to patch gtk to handle
[NSView shouldDelayWindowOrderingForEvent] and explicitly reorder
siblings of a common parent window.
This fixes an issue that plugin windows cannot be re-stacked but were
previously always stacked in the order they were opened.
This fixes an issue with plugin state save/restore. Some
require excessive stack to do that (looking at you b.oops.lv2).
The main GUI thread has no stack limit, so this is only an issue
when calling state save/restore from background threads.
Writing partial messages will lead to undefined behavior.
This does not generally happen (LV2 forge prevents overflow
of the Atom buffer itself), however if the GUI is frozen messages
may accumulate in Ardour's Ringbuffer.
Processor::deactivate must not be called concurrently with
processing. e.g. Threading rules https://lv2plug.in/ns/lv2core
This fixes a potential crash when freezing tracks
* If 1 region is selected: suggest "Region-name (Bounced)"
* If more than one region is selected and ..
* all are on different tracks: allow to specify suffix.
* at least two regions are on the same track: hide the
"add to trigger-slot" option, allow to specify suffix
see also https://discourse.ardour.org/t/bounce-regions-with-names/107863
Since momentary override is a singleton, it needs to remain
GUI only, and not a session API available to any UI.
The middle-clicked button is rendered as pressed. So it is
already obvious and the Changed() signal that is emitted
when temporarily restoring a scene can simply be ignored.
* first_mark_after() correctly expects a timepos_t to compare with locations
* BUT the playhead position is always in samples, by definition
* in many cases this meant the 'next' marker was the one you are already located at
* also remove the slight distinction between playhead cursor and actual play position
(shouldn't matter, but...)
* in the past, the default behavior was: hiding a group would disable it,
and then showing the group would re-enable it
* problem occurs when user has disabled a group; hiding and showing it
unexpectedly re-enable the group
* there was a config variable to disable this behavior, but it was never
shown on the GUI and therefore not discoverable
Despite the longstanding policy, there's really no reason for
group visibility and enablement to be intertwined.
If this chnage causes a big problem for someone, they can revert to
the prior behavior by setting the new config variable in the text file
