[sldev] [QUESTION] What was issue SL-35450

[alissa_sabre at yahoo.co.jp]

I need a help from a Linden.

Quick question:

    What was the issue SL-35450?

Longer question:

In the viewer source file linden/indra/llwindow/llwindowsdl.cpp, there
is a method LLWindowSDL::gatherInput().  In the method, there is a GTK
event loop to drive SL viewer's embedded web browser.  It is enclosed
by some unusual codes with the following comment:

    // Yuck, Mozilla's GTK callbacks play with the locale - push/pop
    // the locale to protect it, as exotic/non-C locales
    // causes our code lots of general critical weirdness
    // and crashness. (SL-35450)

So, the enclosing codes solve a problem identified by SL-35450.  To
understand the problem, I disabled the "push/pop" codes, and tested
the resulting viewer.  Unfortunately (or, fortunately?  :-) the viewer
ran with no weiredness or crash.  I guess I didn't hit the trigger of
the problem in my test run.

Searching the public JIRA with SL-35450 found nothing.

I guess this is an LL internal bug tracking number before the viewer
source was open-sourced.  I want to know what was the weired and/or
crashing behaviour before the fix and possibly a repro so that I can
observe what happens if I run the GTK event loop in non C locale.

Background:

I'm recently making some research/experiment on use of GTK immodule
API to replace XIM in the Linux version of the SL viewer.  (See JIRA
issue VWR-2261 filed by Tofu.)

One of the possibility under eveluation is to use GTK event loop for
keyboard handling entirely.  To do so, GTK event loop should be run
under the user's locale, since most of the Chinese/Japanese/Korean
immodule doesn't work in C locale, and many immodules interact with
GDK event handling layer directly (through event hooks and signals,
for example).

    Alissa
--------------------------------------
Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar
http://pr.mail.yahoo.co.jp/toolbar/