the rest from `tools/convert_boost.sh`.
* replace boost::function, boost::bind with std::function and std::bind.
This required some manual fixes, notably std::placeholders,
some static_casts<>, and boost::function::clear -> = {}.
We cannot switch on a leave event from a widget, because the undo/redo menu items must remain
labelled until we are actually in a new editing context. So switch when we switch tabs
or when we edit the (MIDI) cue editor
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.
Much like the edit-tool and grid-types, clock-modes are UI state.
Saving the UI state separately allows them to be used
consistently for new sessions. Previously clock-modes were set
initially (at application start) and when loading sessions.
The clock modes of newly created sessions was different
depending on loading another session prior to creating the
session. This is now no longer the case.
Previously this setting was ignored. It is relevant when loading a demo
session, where initially there is no user Config instant.xml.
ARDOUR_UI::setup_windows is called directly after the engine starts, but
before the session is set.
This is in preparation for allowing to drag trigger-regions
or trigger-slots. Those will not use a static singleton
PublicEditor API.
Additionally this constrains Ardour-internal drags to Ardour
(via Gtk::TARGET_SAME_APP).
* remember window visibility, size and position
* Show as toggle in the window-menu (rather than show action)
* reduce specialization, use WM and ArdourWindow infrastructure
(transient parent, window-type, etc)
Windows managed as Proxy do not need direct calls to set_session().
This is already handled by WM::Manager::instance().set_session()
Also WM set_session() called it twice.
The initial calls in `we_have_dependents()` was redundantly setting
all widows to "Hidden", before the actual state was known.
tabbable_state_change() is initially called for all Tabs:
ARDOUR_UI::setup_windows -> add_to_notebook() -> attach(),
or for detached windows Tabbable::set_state() -> hide_tab().
Step_up/down_through_tabs used window visibility to determine
candidates. This incorrectly considered detached visible tabs.
Detached windows cannot be cycled to.
This also addressed an issue where tab-buttons state was
incorrectly unset what unrelated tab state changed.
ImplicitActive of the currently active tab is now retained
when some other window is attached/detached.
Actions for hide/show/attach/detach tabbables use hard-coded names which are not
translated. Using Tabbable/WindowProxy::name() to lookup the action will fail,
since the name can be translated. This changes just removes the option to not
provide a menu-name when creating these objects, and uses the name menu-name
when looking up an action by name
This specific change has broader scope than the bare minimum required - we could just move/replicate transport_ctrl.set_session()
after session_sensitive_actions have had their sensitivity set to true. But this "seems" like a more thorough solution,
in that it sets all relevant actions groups before doing anythng else.
This forces saving session-specific GUI settings (Playhead
position, zoom/scroll with stationary PH, window and pane
positions, etc.
While many GUI operations immediately cause an instant.xml
save, changing the playhead-pos in particular does not, nor
mark the session as modified.
This fixes an issue:
1. open session
2. move playhead
3. close session
4. re-open session, expect playhead at position from (2)
