eg. at the end of a loop, the session may already be playing the
beginning of the loop. The TransportLooped signal was emitted.
Yet due to playback latency, the audible frame is still at the end of
the loop.
To interpolate the playhead position the UI needs to be able to know:
Relying on the TransportLooped signal is not sufficient because it
does not take playback latency into account.
Lua serialize() is called recursively and concatenates strings.
(in Lua that results in a new string on the stack, with 2 unused old
strings). Collecting garbage every time becomes expensive, so do it
only once at the end. GUI scripts are not memory limited anyway.
This reverts commit b3722f7063.
In some cases ardour shows context-menu on right-mouse-button
release. In this case selecting a menu-entry should happen
with the left-mouse button (or any button?!)
Using ev->button is only correct if the menu is temporary and only
visible while the button is held, button release then activates the
menu-item.
This needs further work, in some cases allowing any button (0) to work
makes sense and overall consistency needs to be improved.
Different places use different strategies for context-menus which
don't always match the button used in the event-handler.
This is a hotfix (to make TAV context menus work again with left-click)
since 6dc3bdf, a const string reference would leave scope with Lua code
fn("text")
calling a C++
fn (const std::string&)
before the C++ function is called.
Various GdkEvents are not yet handled correctly, eg. unpacking a widget
from its container does not unmap it, nor are remaining widgets in the
contained re-positioned (size allocation does not change, nor does the
mapping). This affects eg. Mixbus Strips
This fixes an -Woverloaded-virtual ambiguity introduced in b5e613d45
void render (cairo_t*, cairo_rectagle*)
void render (Cairo::RefPtr<Cairo::Context> const&, cairo_rectangle_t*)
ArdourCanvas prefers cairomm and CairoWidget itself uses Cairo::Context,
this improves overall API consistency.
