[MPlayer-dev-eng] locale in GUI

[Reimar Döffinger]

Dan Oscarsson <Dan.Oscarsson at tieto.com> wrote:

>ons 2013-03-13 klockan 08:40 +0100 skrev Reimar Döffinger:
>> On 13 Mar 2013, at 08:10, Dan Oscarsson <Dan.Oscarsson at tieto.com>
>wrote:
>> > tis 2013-03-12 klockan 19:38 +0100 skrev Reimar Döffinger:
>> > 
>> >> Second, not supporting anything other that UTF-8 should result in
>> >> clear and reproducible behaviour, the current code is open to
>mysterious
>> >> failures depending on some environment variables almost nobody
>knows
>> >> about.
>> > 
>> > We could split mplayer into "server" part and user part. Where
>server
>> > part only uses C locale. That way the GUI could do what ever it
>wants
>> > with locale and the server part will not be affected.
>> 
>> Why did you quote just that part of my email? Whether setlocale is
>> used or not does not affect the issues with file name encoding much.
>
>Because I was thinking on other things related to locale (date format,
>number format etc) that a GUI should also handle.
>
>> Anyway that is already how all MPlayer GUIs are supposed to work,
>just
>> our own isn't (yet?).
>
>And as long as our own is not in a separate process we will have this
>problem. So to really fix this we should remove the GUI code from
>mplayer and create a separate GUI program.

It's up to Ingo which way he wants to take the GUI.
However a separate GUI doesn't solve anything, you still need to use the C locale e.g. for parsing the GUI's config files for example.
The only things it does is:
1) make it the GUI developer's problem instead of ours (not a help when talking about our GUI)
2) make hacks/workarounds more manageable due to less code being involved (plus a lot of GUIs do not use threads yet).

The only real fix is to get rid of setlocale on an API level and replace it by something that works.
The xlocale stuff is a non-portable hack that makes setlocale semi-usable again for the moment, but it's still a hack.