I used the Widget::on_hide method in the ExportFileDialog to defer the saving
of changes in state of the analysis and soundcloud-upload checkboxes as it was
not possible to save the format xml state directly from the
ToggleButton::toggled() signal as it created a recursive loop and also to
prevent saving the state more than once.
Even though the ExportProfileManager::FormatListChanged signal is no longer
emitted when saving format state and the crash no longer occurs without this
change. I think it is worth saving explicitily from in the toggle callbacks to
reduce the complexity of understanding what is taking place and when even if it
is less efficient.
There is definitely more opportunity for refactoring and redesign.
This is not caused by commit_reversible_command, but because
NoteDrag::total_dx calls Evoral::Note<Evoral::Beats>::time()
with invalid MIDI note (deleted).
This should be a proper fix for bug #7003, now that I've spent a bit more time
reading the code. The options are now stored as part of the export format
state.
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.
