The default scheduling on windows seems fairly erratic or is at least in the
VM that I'm running these tests on, so increase the timing slack a bit so the
test has a better chance of passing. It is still quite easy for it to fail
though, especially if you for instance manipulate the terminal window somehow
while running the tests but it does not really matter in any case as this test
serves its purpose in testing the PBD::MMTimers API.
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.
The issue is that when ExportDialog is destroyed
ExportFileNotebook::FilePage::on_hide is called which in turn calls
ExportProfileManager::save_format_to_disk() in order to save changes to the
analysis and soundcloud upload checkboxes. This then causes the
ExportProfileManager::FormatListChanged signal to be emitted, which in all
other cases is emitted when the format list is modified so that the GUI can
rebuild the format selector menu in ExportFormatSelector::update_format_list
when a format is added or removed.
The problem when doing this in the destructor is that some of the widgets have
already been destroyed, specifically the issue was in
ExportFileNotebook::update_soundcloud_upload trying to access the
soundcloud_selector member that had already had its destructor called.
As it is not necessary to call this signal in the first place and it just
causes unnecessary GUI updates remove the signal emission.
This is not caused by commit_reversible_command, but because
NoteDrag::total_dx calls Evoral::Note<Evoral::Beats>::time()
with invalid MIDI note (deleted).
let the user/developer know if this does occur rather than just silently
skipping the file.
Fix some whitespace issues while we are changing indentation.
The paths are in UTF-8 encoding and ::rename expects paths in the system
codepage encoding so ::rename will fail for any paths that contain characters
that aren't in the system codepage.
This fixes Flush Wastebasket on Windows where paths contain characters that
aren't in the system codepage(usually most non-ascii characters).
The path is in UTF-8 encoding so use Glib functions to properly support paths
containing characters that aren't in the system codepage.
This fixes Clean-up Unused Sources on Windows where paths contain characters
that aren't in the system codepage(usually most non-ascii characters).
_USE_MATH_DEFINES is required for M_PI
WIN32 is no longer defined by gcc/mingw with --cxx11 option enabled(of course
_WIN32 still is) but as it is used in a liblo header(even though it is probably
incorrect to do so) define it.
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.
Some Mixbus users (on Windows) have reported seeing ludicrously high figures for the amount of disk space that'll be recovered if they choose to clean up unused sources. I can't see anything obviously wrong in Ardour's code - except for one situation where we don't check a return value after calling 'g_stat()'.
On Windows, the relevant path should be (hopefully!) in UTF8 format and the first thing that g_stat() does is to convert it to UTF16. If that conversion fails for some reason, g_stat() will return an error status and statbuf will be uninitialized - but at the moment, we're not checking this. As an experiment, let's check the returned value and find out if these user reports go away.
Unfortunately, if it does fix the problem then we've got an even bigger problem - because somehow, a Windows user can create source files with invalid names which can't be later deleted!!
