There were two issues:
The first is that TrimDrag::aborted was calling TrimDrag::finished with a null
GdkEvent which caused a segfault when dereferencing. So avoid that by passing
in a dummy event as we are just going to undo the operation in the next step
anyway so it shouldn't matter if it is valid(AFAICT).
The other is that TrimDrag:aborted was calling Editor::undo() which was in turn
calling TrimDrag::aborted leading to infinite recursion and stack overflow.
Calling Session::undo() directly seems to avoid that issue.
This fix feels like a bit of a hack...but it seems to work and is better than a
crash.
This commit changes item "gtk_bases" from light (color22) to darker (color88). The knob of "Enable/Disable MIDI input" in Edit List had the same colour and was not visible. This commit makes it clear visible, and it has no much influence on a general design.
- after reports that a tempo with non-4.0 note type
would produce a ramp in the preceding section, an incorrect
assumption was made leading to a bogus 'fix' that redefined
Tempo's pulses_per_minute().
the real fix was simple:
the ramp's function constant was calculated using the note type
of the proceding tempo rather than the current one.
- this patch reverts e82482e8e9 and a4d67279e0
and maintains the old definition of Tempo::pulses_per_minute()
It seems that 'strftime()' (on Windows) works differently from its non-Windows counterparts. Specifically, some formatting options (e.g. %F) are not recognised in the Windows implementation.
Fortunately, glibmm comes to our rescue here! So let's use the glib implementation which will hopefully work the same on all platforms.
GTK+ apparently unpacks/hides a widget whose requistion at window show/packing time is negative for x or y axes. The RC option editor
was being created AFTER its Tabbable self packed it into its own window (when detached), and GTK+ rejected it because the
treeview had a size requisition with -1 for width.
So build it first, then call Tabbable::set_state() later
Don't try to be smart when chosing which parameters need their
automation updated but rather trust the list that was populated at
creation time when all relevant information had been gathered.
When requesting a size for ArdourButton, the width and height of the
button could be increased by one to ensure the center of the text would
lie exactly at the center of the button.
I initially thought that it was a good idea even when the text used for
sizing was frozen, but the main (and only?) use-case for that is to
actually freeze the size of the button regardless of the actual
displayed text, so jittering by one pixel is not welcome.
Only do the centering tweak if there is no sizing text.
Remove the LocaleGuard so that the value of LC_NUMERIC is that of the users
locale and sscanf will parse the string correctly. For instance, with a locale
like nl_NL or fr_FR where the decimal point is different than the "C" locale,
only the number up to the decimal point will be parsed by sscanf and input
values will be rounded down.
This fixes a crash where aspect ratio "0.5" from harvid was interpreted
as "0" in the French locale (expecting 0,5).
Note: harvid uses a portable, not localized snprintf() implementation
