[Ardour-Dev] Feedback on string-convert branch

Robin Gareus robin at gareus.org
Thu Jan 5 06:56:58 PST 2017


On 01/05/2017 03:36 PM, Robin Gareus wrote:
> On 01/05/2017 12:12 AM, Tim Mayberry wrote:
>> On Thu, Jan 5, 2017 at 7:14 AM, Paul Davis <paul at linuxaudiosystems.com>
>> wrote:
>>
>>>
>>>
>>> On Wed, Jan 4, 2017 at 12:52 PM, Tim Mayberry <mojofunk at gmail.com> wrote:
>>>
>>>> I've pushed a branch called string-convert to the main repository that
>>>> I'd like
>>>> some feedback on from the other developers when they get a chance. It
>>>> represents a fair bit of work over the last year or so and is attempt to
>>>> make
>>>> improvements to the de/serialization code in Ardour.
>>>>
>>>
>>> I still don't understand how this is supposed to work with plugin data. If
>>> you leave the global locale setting untouched, how do we know what to do
>>> when reloading plugin data across two systems where the global locale may
>>> be different?
>>>
>>>
>>
>> Of the 100 or so LocaleGuard's in master, the 10 or so that remain are in
>> the Plugin get/set_state methods, which is why I mentioned removing
>> LocaleGuard's that guard internal string conversion.
> 
> Since changing the locale is expensive, so we should also retain a
> single LocaleGuard in save_state() rather than switch forth/back in
> every Plugin get/set state.
> 
> With some luck, plugins don't change the locale and every save only
> needs to change the locale once.
> 
> 
>> That some plugins depend on a specific global locale for correct operation
>> or worse modify the global locale is dissappointing but seems to be a
>> reality and it is accounted for in the branch.
> 
> ..and it's worse. 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.
> 

PS. The recent code to only set LC_MESSAGES is step in that direction.

For now the intention is to investigate and to collect feedback from
various affected systems + plugins.


@Tim: can that code that you wrote also work in the other direction?
Can we use it to format floats with some preferred user's locale (comma,
dot) for display only?




More information about the Ardour-Dev mailing list