This data was generated asynchronously and is not required to be "silenced"
the way that session data would be. Compare also to the similar tests for
sync-related MIDI ports
This is needed for save-as and archiving, LV2 state may not be saved
otherwise if lilv_state_equals() returns true.
Also if thestate is saved as part of save-as or archiving or
template, the state-version did increase.
Upcoming normal save will reference a plugin state that does not exist
in the current session bundle.
state-restore does not set the same flag, so lilv_state_equals()
returns false even for identical states and a new state is saved regardless
actual fix also depends on http://dev.drobilla.net/ticket/1145
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.
