Kazuki IWAMOTO
iwm****@maid*****
2004年 8月 31日 (火) 01:12:57 JST
岩本一樹です。
> imime.c sets itself as default for all languages ("*" in the
> GtkIMContextInfo struct). It probably should be default for
> "ja:ko:zh"?
"ja:ko:zh"だけがimimeを必要としているのか、わかりませんが、
私もimimeが必要だと思われる言語は"ja:ko:zh"しか知りません。
とりあえず"ja:ko:zh"にしておいて、必要なことがわかれば、
追加すれば良いと思います。
> gtkimcontextime.c uses #ifdef UNICODE to switch between the wide-char
> and multibyte ("ANSI") API at compile-time. No GTK+ code is built with
> UNICODE defined. Instead it could use G_WIN32_HAVE_WIDECHAR_API() (in
> HEAD GLib) to decide at run-time which one to use. (We also should add
> more stuff like that in gdk/win32, to for instance set window titles
> using the wide-char API if available.)
実はGLib-2.5.2のアーカイブをダウンロードして構築を試みたのですが、
G_WIN32_HAVE_WIDECHAR_API()を呼び出している個所があって、
しかもG_WIN32_HAVE_WIDECHAR_API()の実体がなくて、リンクが
通らなかったです。
(まあ名前と使われ方から、どういうAPIかはすぐに察しがつきましたが)
CVSのgwin32.hにはG_WIN32_HAVE_WIDECHAR_API()の実体があって、
#define G_WIN32_IS_NT_BASED() (g_win32_get_windows_version () < 0x80000000)
#define G_WIN32_HAVE_WIDECHAR_API() (G_WIN32_IS_NT_BASED ())
であり、g_win32_get_windows_versionの戻り値はWindows APIの
GetVersionの戻り値そのままみたいです。(私的にはGetVersionExを使えと言いたいが)
要するにG_WIN32_HAVE_WIDECHAR_APIは95/98/MEなら偽を返し、
NT/2000/XPならば真を返します。
私はGTK+は2.4では#define UNICODEのことなんて全く考えていないけど、
将来的には#define UNICODEをサポートするものだと思って、imimeに
#ifdef UNICODEを入れておいた訳です。しかしG_WIN32_HAVE_WIDECHAR_API()
なんていうAPIを新設して、動的に対応するとは思ってもいませんでした。
こういう方法は定石からは外れているので私は不安に思いますが、彼らが
そうすると言うならば、それもまた良いかと...。
次の部分は訳してみます。tml曰く...
> いくつかの(全部?)UNICODE版のImm*系のAPIはWindows 98/MEでも利用可能です。
> しかしWindows 95では利用不可能です。
> Windows 95は無視してしまうか(常にUNICODE版のImm*系のAPIを使う)、
> またはg_win32_get_windows_version()の戻り値で95と98/Meで分岐しましょう。
> 後者の場合、Windows 95のDLLはダミーのエントリーポイントをエクスポート
> していないので、私たちがWindows 95に対応したいならば、
> 実行時にAPIの名前でAPIのエントリーポイントを求めなくてはならない。
それで足永さんの答えとしては、Windows 95の無視には賛成というわけですね。
GLib/GTK+本体がG_WIN32_HAVE_WIDECHAR_API()という手法を用いる以上、
Windows 95ではダミーのエントリーポイントが用意されていないAPIを使うという
事態が想定できるわけで、imimeがWindows 95のサポートを続けても無意味な
抵抗だと思います。私もimimeがWindows 95を無視することに消極的に賛成です。
(私的にはGLib/GTK+本体も含めてWindows 95のサポートを続けるべきだと思います。)
しかしならが、Windows 98/MEでUNICODE版のImm*系のAPIが利用可能というのは
本当でしょうか? tml自身も「Some(いくつか)」って言っているし、
常にUNICODE版のImm*系のAPIを使って安全なのか、私にはわかりません。
UNICODE版のAPIがエクスポートされていても、それがダミーで実際には機能しない
なんてこともありうるし、初期のWindows 98と末期のWindows 98では
かなり内部が異なるような...。
私ならば、UNICODE版のImm*系のAPIが確実に使えるWindows NT/2000/XPでのみ
UNICODE版のImm*系のAPIを使うようにします。要するに「#ifdef UNICODE」を
「if (G_WIN32_HAVE_WIDECHAR_API())」に置き換えます。(そのほうが安全だから)
バグ報告を出さない選択肢としては、これが最良だと思います。
しかしここはtmlの提案である、「常にUNICODE版のImm*系のAPIを使う」に
賛同してみるのも、良いかも知れません。あえてバグ報告が出そうな選択肢を選んで、
バグ報告を出させて最良の選択肢を探るというのも手段としてはアリだと思います。
(バグ報告が出ても私には何の損害も無いしね。)
岩本一樹
iwm****@maid*****