[SCIM] BUG: locale dependency of SCIM's gtk2-immodule

[Zhe Su]

Hi,
  Using IMEngines which do not support EUC-JP encoding in gtk2 apps
under ja_JP.eucJP locale makes no sense, because the client can not
store the content into file, even it uses UTF-8 as internal encoding.

  If you can not use uim-anthy under ja_JP.eucJP locale with the
original SCIM code, there must be a bug in src/scim_utility.cpp.

  Please read the source code of IMEngineFactoryBase::set_languages ()
and scim_get_language_locales (), to see how SCIM works.

  Currently SCIM will only try the ja locales: ja_JP.UTF-8,
ja_JP.EUC-JP, ja_JP.SJIS and ja_JP in order. If your system does not
support ja_JP.EUC-JP or ja_JP locales, then SCIM will assume that your
system does not support EUC-JP encoding, then uim-anthy won't be
activated under ja_JP.eucJP locale.

  I think the standard locale name should be ja_JP or ja_JP.EUC-JP.
ja_JP.eucJP should be a non-standard name. Correct me if I'm wrong.

Regards
James Su

On Sat, 26 Jun 2004 13:08:05 +0900, YamaKen <yamaken at bp.iij4u.or.jp> wrote:
> 
> Hi James,
> 
> At Sat, 26 Jun 2004 11:03:25 +0800,
> james.su at gmail.com wrote:
> >
> > Hi,
> >   Thank you very much. But for the first issue, the original code is
> > used to filter out the IMEngines which do not support the current
> > locale's encoding. The real issue is in
> 
> You have to filter out IMEngines based on GTK+'s internal
> encoding UTF-8, rather than current locale's encoding. My patch
> performs so.
> 
> "current locale's encondig" makes no sense for
> gkt-immodules. GTK+'s internal string encoding is fixed to UTF-8
> regardless of current locale's encoding.
> 
> I want to use UTF-8 IMEngines on ja_JP.eucJP locale. Your code
> filters out my necessary engines such as uim-anthy.
> 
> > gtk_im_context_scim_filter_keypress, which should send back the key
> > event if context_scim->impl is NULL.
> 
> Yes, I know. Whether keys are sent back or not is not important
> because both are useless. To eliminate the (context_scim->impl
> == NULL) condition caused by locale dependency is what have to
> do.
> 
> >   I had fixed this issue in CVS, you may try again.
> >
> > Regards
> > James Su
> >
> > On Sat, 26 Jun 2004 09:12:51 +0900, YamaKen <yamaken at bp.iij4u.or.jp> wrote:
> > >
> > > Hi, I've removed the bugs that prevented me from running
> > > scim-uim through SCIM's gtk-immodule on my machines. Please
> > > apply attached patch.
> > >
> > > first bug:
> > >
> > > SCIM's gtk-immodule requires UTF-8 locale, but the requirement
> > > is inappropriate. For example, many of Japanese are setting
> > > locale to ja_JP.EUC-JP so g_get_charset() returns "EUC-JP". This
> > > causes that EUC-JP string is passed to the immodule that assumes
> > > string as UTF-8. Or if IMEngine does not supports current
> > > locale, its instantiation fails and key inputs are simply
> > > discarded and not echoed back. scim-uim is a such case.
> > >
> > > Although this problem can be avoided by setting the env
> > > CHARSET=UTF-8 to instruct glib to use UTF-8, it is wrong
> > > way. Fixing client-side encoding to UTF-8 regardless of current
> > > locale is correct way. This also enables scim-uim to be running
> > > on some environments that not having UTF-8 locale.
> > >
> > > second bug:
> > >
> > > When IMEngine instantiation is failed ("key inputs are simply
> > > discarded and not echoed back" state), SCIM's gtk-immodule is
> > > crashed by following steps.
> > >
> > > $ LC_ALL=C gedit
> > > # (re)select SCIM immodule from context menu
> > > # crashed
> > >
> > > This bug has been fixed by modifying
> > > gtk_im_context_scim_get_preedit_string().
> > >
> > > I've started to play with SCIM.
> 
> -------------------------------
> YamaKen  yamaken at bp.iij4u.or.jp
> 
> _______________________________________________
> scim mailing list
> scim at freedesktop.org
> http://freedesktop.org/mailman/listinfo/scim
>