Re: Feedback on string-convert branch

On Fri, Jan 6, 2017 at 8:48 PM, John Emmas <[email protected]> wrote:

> On 05/01/2017 14:36, Robin Gareus wrote:
>
>>
>> Some plugins expect to also *run* in the "C" or en_US locale.
>> e.g. NI Kontakt fails in numeric-locales that use a comma, and
>> NI isn't alone.
>>
>>
>> If we add a custom system, I think it's better to
>>
>>   - don't change the locale at all, keep using the default "C" locale for
>> C++/std::locale
>>
>>   - keep relying on standard functions for string-conversion
>>
>> and instead
>>
>>   - come up with a custom message-translation system that does not depend
>> on the std::locale at the time the message is formatted.
>>
>>
> Is this predominantly a Windows problem or do the other OS's also suffer
> from it?
>
>
It is a problem that is relevent on any platform, If a plugin uses C/C++
library functions that are dependent on the global locale then numeric
conversion will use the global locale setting for conversion.

I only realised yesterday that on Windows, it seems to be possible for
> different threads (within the same application) to use different locale
> settings.  I haven't tested it in earnest but see the example at the bottom
> of this page:-
>
> https://msdn.microsoft.com/en-us/library/x99tb11d.aspx
>
> Would that help at all?


I mentioned in the original email that some platforms (well actually, only
Windows that I know of) support per thread locale. It isn't helpful as the
serialization/numeric conversion occurs in the GUI thread which needs the
locale to be set/reset to the users preferred locale for localization
anyway. If Ardour had been designed/implemented as some applications are to
save/load state in a separate thread then it might be useful, but as it is
platform specific and there are better solutions it isn't really of
interest.

Tim

_______________________________________________
ardour-dev mailing list
[email protected]
http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour.org