This was lost when refactoring the editor lists into dedicated
Region, Source and Route lists. A patched version of gtk allows to
initiate a drag, rather than a name edit.
On modern systems `xdg-screensaver reset` does not necessarily
reset the timer. It depends on DPMS, and according to spec turns off
the screensaver (unlock the screen), via `xset dpms force on`.
Explicit window suspend/resume make use of DBus
org.freedesktop.ScreenSaver.Inhibit, which is not be supported
but all systems, so we fall back to good old `XResetScreenSaver`
which does reset the activation timer.
Window size has to be set before calling `setup_toplevel_window()`.
and `set_show_tabs()` - see also acf13e9498 and 42cb321039.
This also unconditionally saves the current settings to global config
instant.xml. This was previously only done in rare cases when first
closing the session and then quitting Ardour.
These were preventing Ardour from compiling on Windows (Clang or MSVC)
Possibly would've been buildable with MinGW but I don't have that available to test.
At present, TempoTwist is Primary-drag on the tempo ruler, and TempoCurve is Primary-drag on the meter
ruler. Not sure that this is quite what we want here, but it makes more sense than the prior
design, in which TempoTwist was available from non-tempo-related rulers
This avoids breaking bindings, and since the action name is generally not a part of the GUI,
really doesn't hurt anything in terms of understandability
An attempt to satisfy #8848.
Add a new action, "fork-regions-from-unselected", which unlinks all
selected MIDI regions from any unselected regions, but maintains links
within the selection, and add the new action to the region MIDI context
menu as "Unlink from unselected". Rename the existing "fork-region" action
to "fork-selected-regions", and amend the existing "Unlink from other
copies" menu item to "Unlink all selected regions" to (try to) clarify the
difference.
Attach the <Tertiary>U default key-binding to the new action: I personally
think it's generally slightly more useful (otherwise I wouldn't have
implemented it), though I'm not that fussed.
In the case that there's only one MIDI region selected, or that none of
the selected regions are mutually linked, both actions will have exactly
the same result. Ideally, we'd only show a single menu item in this case,
but that would require (a) implementing a function to check whether the
selection contains any linked regions, and (b) making the region MIDI
context sub-menu dynamically generated, so that it can change based on the
result of that function, neither of which I've tried to do yet.
