This should be the final part of a fix for bug #7025, which means the id
property of PBD::Controllable is restored and a new id is not generated at
first save.
I'm assuming this was a typo, comparing with the wrong name meant the state of
the MuteControl was never being restored. This also fixes restoring bindings
associated MuteControl instances.
This is part of a fix for bug #7025 which means the id property of
PBD::Controllable is restored and a new id is not generated at first save.
This also fixes restoring bindings associated SoloControl instances, which is a
bit surprising hasn't been noticed/reported.
This fixes the libpbd testCanonicalPathUTF8 and libardour
open_session_utf8_path unit tests
You can now have Sessions with localized names containing characters that
aren't in the system codepage on Windows.
It also fixes the issue where a Session would not open when it was moved into a
path with characters that aren't in the system codepage.
The only use case for calling canonical_path/realpath on the session path
AFAICT is for resolving relative paths that are passed via the command
line/terminal. I'm doubtful that works correctly on Windows because of
character encoding issues with the current API we use for that(not glib), so it
is slightly ironic that this issue was caused by an incorrect implementation of
a function that is not really necessary on Windows at this point in time.
This currently fails because the windows only realpath implementation in
pbd/pathexpand.cc, which is called from PBD::canonical_path to resolve the path
uses Glib::locale_from/to_utf8. As I demonstrated in the
testOpenFileUTF8Filename test case Glib::locale_from/to_utf8 are not the
correct functions to use for this use case as it converts to/from utf-8 to the
locale's current character encoding. On Windows this is most often a single
byte encoding such as Windows-1252 and conversion will fail if the path
contains any characters that are not in system codepage.
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!!
