[OpenIndiana-discuss] [developer] Gnome and the future
Irek Szczesniak
iszczesniak at gmail.com
Sun Nov 4 20:01:31 UTC 2012
On Sun, Nov 4, 2012 at 4:17 PM, Alex Caudill <alex.caudill at gmail.com> wrote:
> On Sun, Nov 4, 2012 at 9:46 AM, James Carlson <carlsonj at workingcode.com> wrote:
>> On 11/04/12 09:06, Irek Szczesniak wrote:
>>> This is useless because you still do not have newlocale(), duplocale()
>>> or uselocale() which create or use the locale_t object.
>>
>> Those can be dummied out as well.
>
> For example:
>
> http://git.musl-libc.org/cgit/musl/tree/src/locale/duplocale.c
> http://git.musl-libc.org/cgit/musl/tree/src/locale/freelocale.c
> http://git.musl-libc.org/cgit/musl/tree/src/locale/newlocale.c
> http://git.musl-libc.org/cgit/musl/tree/src/locale/setlocale.c
>
> I'm actually using this code nearly verbatim on OpenIndiana.
>
>>
>>> The point of the new apis is that you can have an unlimited number of
>>> locale_t objects, all with different properties. As side effect
>>> different threads can use different locale_t objects, giving threads
>>> the ability to run in different locales. But this feature is NOT
>>> limited to per-thread locales as some people may think.
>>
>> I think the underlying point that the previous poster was making was
>> that for a significant number of users, the desktop environment is
>> launched with the per-process locale set correctly, and the user happily
>> spends all of his time in that single locale. Being able to switch
>> locales on a thread-by-thread basis is certainly nifty, and is perhaps
>> useful in some service providing scenarios (e.g., a web server), but
>> it's quite unclear at least to me how it'd be very much helpful to build
>> a window manager. Perhaps there are multi-lingual people who really do
>> need to have a window manager that can decorate each window differently
>> ... but really?
>
> I just wanted to share an approach for Getting This Stuff To Work(TM).
How is this going to work when do run in one locale and do
towctrans_l() in a different locale? Or use the collation order of
de_DE.UTF-8 while the main locale is en_US.UTF-8? There are so many
cases where this is going to fail or going to introduce subtle, stupid
or plain dataloss bugs that it hurts.
Irek
More information about the OpenIndiana-discuss
mailing list