Arodur itself on longer depends on C/C++ locale for saving/loading sessions.
However, the Localeguard is kept for 3rd party plugins: Reset the C locale
to "C" to enforce consisten numerics and portable sessions as well
as verify that no plugin changes the C++ locale.
Ardour translations and GUI string formatting only depends on the C locale.
Modifying the C++ locale may produce erratic results on various systems
(in particular OSX and macOS) and cause incompatibilies with plugins.
GTK events are still handled while un/loading a session (e.g display
"Loading" message or showing the splash triggers an event-loop run).
Global canvas elements (e.g. Rulers) may respond to session-specific
actions.
Since 5.8-245-g3e43585fa, a response hides the dialog Window
in ArdourDialog::on_response (to prevent dialogs windows staying
around unresponsively while Ardour does background work).
This logic does not apply to Dialog Windows which implement
ProgressReporter or support dialog responses other than OK, Close.
The monitor section connection is implicit and done by default.
This fixes an issue with the auditioner connections being lost when
switching between sessions that use/don't use the monitor-section.
Previously:
1) load session with monitor section, save session
-> global config explicitly saved
"auditioner-output-left" -> "ardour:Monitor/audio_in 1"
2) Load a session w/o monitor-section. The config is parsed,
"ardour:Monitor/audio_in" port does not exist, connection was lost.
All uses of this function have now been replaced by PBD::to_string() from
pbd/string_convert.h
Remove this function so that it isn't mistakenly used to perform numeric to
string conversion when the result is being used for serialization as that only
works if the global C++ locale is set with LC_NUMERIC=C, which is the case
currently but may not be in the future.
The numeric formatting is equivalent. Even though this string is being used in
the UI as a label I think this is another case where we don't want a localized
numeric string, which would only be relevant with a track count >=1000.
The numeric formatting is equivalent. The string is being used in a label so it
could be argued that we want localized numeric formatting in this case, but as
it is only relevant if we have >=1000 meter strip keep it the same for now.
The C++ global locale is currently set to LC_NUMERIC=C by the first instance of
LocaleGuard so this change means numeric formatting is equivalent.
As the string is being used to construct a label, perhaps we do want to
generate localized numeric formatting in this case. Anyway keep it the same for
now.
The numeric formatting is equivalent to iostreams when global C++ locale is set
to "C" without the need for a LocaleGuard.
I'm not sure this would have been an issue as the number of VCA's may never get
high enough for digit grouping of the locale to affect numeric output, but now
it is not a possibility.
Use pbd/string_convert.h API instead of std::ostream for numeric formatting to
remain locale independent and not have to use a LocaleGuard. The formatting is
equivalent.
Use pbd/string_convert.h API instead of std::ostream for numeric formatting to
remain locale independent and not have to use a LocaleGuard. The formatting
is equivalent.
The code in this file has been disabled in the GUI for some time...and I doubt
it would now work correctly.
Use pbd/string_convert.h API instead of std::ostream for numeric formatting to
remain locale independent and not have to use a LocaleGuard. The formatting is
equivalent
This avoids requiring a LocaleGuard to get the correct numeric formatting and
saves/restores the automation data to the precision required for roundtrip
equality.
Possible issue with numeric formatting using std::streams in locales with
grouping. Although I don't think it would be an issue in this case use locale
independant alternative for numeric formatting anyway.
string_compose uses std::ostream/stringstream which will insert thousands
separators in some locales. This was not a problem when LocaleGuard set the
global C++ locale to "C"
std::ostream/stringstream will use the current locale to determine the numeric
formatting. If the locale uses grouping then thousands separators will be
inserted in the output which produces an invalid color string in
UIConfiguration::reset_gtk_theme() and when converting colors to strings in
UIConfiguration::store_color_theme()
This has not been a problem so far because it appears that LocaleGuard does not
reset the LC_NUMERIC value for the global C++ locale. So if a LocaleGuard is
created at any time before these functions are called(even if it goes out of
scope) the numeric formatting used by std::streams will use the "C" locale
formatting facets.
