This commit leaves two issues outstanding:
1. unclear/ugly semantics for drag operations that reset the GUI thread's tempo map to the writable copy
2. undo/redo for the tempo map
These will be addressed in future commits
This commit leaves two issues outstanding:
1. unclear/ugly semantics for drag operations that reset the GUI thread's tempo map to the writable copy
2. undo/redo for the tempo map
These will be addressed in future commits
Found via `codespell -q 3 -S *.po,./share/patchfiles,./libs -L ba,buss,busses,doubleclick,hsi,ontop,ro,seh,siz,sord,sur,te,trough,ue`
Follow-up to 364f2f078
When building with --use-external-libs on Fedora, Ardour would fail at
runtime with messages like:
symbol lookup error: .../vamp/libardourvampplugins.so: undefined symbol: kiss_fftr_alloc
Try to automate handling of this error situation.
Fedora packaging worked around it with a custom patch that we rather
would avoid:
https://src.fedoraproject.org/rpms/ardour6/blob/rawhide/f/ardour6-missing-kissfft.patch .
Both of these are currently needed: idle_resize() is required for
::set_height() to take effect on all affected tracks, and
::redisplay_track_views() is needed to reposition all other tracks as
necessary.
This may be incorrect, since track height changes may be driven
directly (e.g. via menu items) rather than by mouse drags. This may
need revisiting and there may need to be a way to separate dragged height
changes from others.
This allows it to be used in an idle callback. If we use
::redisplay_track_views() directly, we do not disconnect the idle
connection. This will happen automatically since the callback will return
false, but it seems better to explicit about this. Even better would be to use
::connect_once() but this may not be available in the version of glibmm that we
are using at present.
It appears that GDK/glib will not run idle callbacks with a lower priority than
HIGH_IDLE+10 *if* a new user input event is pending. This means that if mouse
motion events are arriving and causing resizes of selected tracks, the call
to ::redisplay_track_views() which is needed to update all the other tracks,
will not take place if a new motion event arrives. Changing the priority to
same as is used for the ::idle_resize() callback prevents new motion events
from being handled before ::redisplay_track_views() is called.
