WindowMaker の最新では utf-8 になってるので、ちゃんと日本語タイトルが表示されます。 ○ WindowMaker-0.91.0-0vl3 -- OK ● WindowMaker-0.80.2-0vl3 -- NG でも、昨日は gnome も ok と書いたけど勘違い。うまく表示できません。 WM タイトルには euc-jp でも utf-8 でもそれなりに渡ってるみたいですが、表示は NG。 文字化けしてるだけで、表示桁は合ってるので、フォントの設定らしい。 XSetWMName() で渡してるので、ウィンドウマネージャが XGetWMName() で受け取った後の処理の話し。 いろいろ問題があるので、週末 upload の予定は止めるつもり。ウィンドウマネージャは他にもあるし。 Tk だけのせいじゃ無いようです。ごめんなさい。 追記: つい最近出た tk-8.4.10 に対応コードがありました。やはり問題があるのは解かってたらしい。古いコードに、追加する形式で修正されていたので、パクリました。ただ、tk-8.4.10 にするのは、他に影響が多いので、余裕がある時期に、いずれ。 と云うわけでパッチを修正しました(ファイル名は同じ) ftp://owa.as.wakwak.ne.jp/pub/Vine/VineSeed/patch/tk-8.4.6-tkUnixWm.patch

>>243 多分 tk8.4.6/unix/tkUnixWm.c の XSetWMName あたりの間違いか、環境設定 やはり tk のせい? tk8.4.6/unix/tkUnixWm.c の中では、ロケールにしたがって WM タイトルを書き出してます。 一方、最近の X11 は utf-8 でタイトルを書かないといけないみたい (自信なし)。 うちの WindowMaker 環境ではそのようです。X11 の環境変数にでも書いてあるのかな。 というわけでパッチ作成 ftp://owa.as.wakwak.ne.jp/pub/vine/4.0/patch/tk-8.4.6-tkUnixWm.patch いまのところ、tk や tkinter でうまく日本語タイトル表示されてます。 追記: どうせ忘れるので、tk でのタイトルなどの表示方法書いて置きます。 $ wish % wm title . "あいう" % wm title . あいう % tk_messageBox -title "かきく" (OK ボタンを押す) % label .label -text "名前:" .label % entry .entry -width 20 -relief sunken -bd 2 -textvariable name .entry % pack .label .entry -side left -padx 1m -pady 2m % ^D 起動→タイトル設定→設定値取得→ダイアログ表示→ラベルとエディットBOX表示→終了

python-PyGreSQL-3.6.2-0vl3 感謝です。 ^ ^/

>>242 Tcl/Tk でウインドウの日本語タイトルが出ません とりあえず Xlib でタイトル表示 (utf-8) のテスト。 ------------------------------------------------------------------------- #include <stdio.h> #include <X11/Xlib.h> #include <X11/Xutil.h> int main() { Display* d = XOpenDisplay(NULL); Window r = RootWindow(d, 0); Window w = XCreateSimpleWindow(d, r, 0, 0, 100, 80, 2, 0, 1); // char* s = u"あいう"; char s[] = {0xe3, 0x81, 0x82, 0xe3, 0x81, 0x84, 0xe3, 0x81, 0x86, 0}; char* sl[1] = {s}; XTextProperty ct; XStringListToTextProperty(sl, 1, &ct); XSetWMName(d, w, &ct); XMapWindow(d, w); XFlush(d); getchar(); XCloseDisplay(d); return 0; } ------------------------------------------------------------------------- $ gcc -I/usr/X11R6/include -L/usr/X11R6/lib -lX11 hoge.c Xlib でタイトル表示はできるど、TclTk で出来ない理由は判りません。 多分 tk8.4.6/unix/tkUnixWm.c の XSetWMName あたりの間違いか、環境設定だろうけど、解かりません。 でも今週は時間がありませんので、深みに嵌まる前に、敵前逃亡します。スマソ;;

Tcl/Tk でウインドウの日本語タイトルが出ません。ascii なら ok。 $ wish % tk_messageBox -title "あいう" 他のウィジェットは正常に日本語が表示されます。出ないのはウィンドウマネージャのタイトルだけ。当然 tkinter の日本語タイトルも出ません。確か Vine-2.9 あたりでは、ちゃんと表示されていたと思う。そのあたりで WindowMaker も Gnome も utf-8 になってるし。Tcl/Tk も utf-8。ただ kterm は euc-jp なので、euc-jp で渡さないといけないのかも? うーん。Tcl/Tk と WindowMaker を最後に upload したのは僕なんだよなー 調べてみますけど、明日は出張なんで、今日は早寝します;;

>>237 pykf, kconv CJKCodecs があるのでいまさらの感じですが、日本語の文字コードを判別する場合に、今だ必須プログラムだと思います。 文字コード変換は、当然 python 標準の CJKCodecs を使うべきです。 なぜ kconv-1.1.8p-3 なのか 1. kconv-1.1.8 C 言語バージョンをなぜ使わないのか C 言語バージョンは落ちると云う話を、昔よく聞きました。情報源は記憶にありません。 現在の安定版は、古いですが 1.1.8p-3 だと考えてます。問題があればパッチを当てることで対処するつもりです。 2. 新しいメンテナの最新版 python-kconv-1.3.1 をなぜ使わないのか 仕様に変更があったのか、動かないと言われたことがあります。またメンテを引き継いだと云われるけど、 http://sourceforge.jp/projects/kconv/ ここを見ると、2003-02-12 のバージョンのまま放置されてます。 どちらも優れたプログラムです。だた本質的に判断できない文字列が存在します。この場合、経験的に pykf は Shft_JIS 側、kconv は euc-jp 側の判断を下すようです。なので、どちらも必要です。適用範囲や対応エンコードも若干異なります。また、これらを利用したプログラムが存在します。たとえば COREBlog や JCodeChanger です。 kconv に関しては、作者が問題ありとしてますので、この辺は考慮しないといけません。 http://apache.noexistent.com/~mak/kconv/kconv/index_jp.html とは云うものの、自分で使った感じでは kconv すばらしいと思ってます。

spec ファイルで python ビルドする時のメモ。 rpm 作成時に、ビルドする場所は ~/rpm/BUILD の下です。そしてインストール場所は別の場所。多くは *.pyc や *.pyo ファイルが出来るのですが、これは少し困ります。インストール後の実行時に例外が起きたりして、エラートレースが表示された場合 ~/rpm/BUILD のディレクトリがまる見えになるからです。本当は実際のインストール場所を表示してほしいです。 python ライブラリの場合は *.pyc, *.pyo は消してしまった方が無難のようです。どうせ import すれば *.pyc は出来ますし、オプティマイズをかけた *.pyo もどれだけ効果があるのか疑わしい。たとえば、こんな記事があります。 http://zenkai.atransia.co.jp/blog/32 python アプリの場合にも、上記のことが云えるのかもしれませんが、独自に手段を用意してるものがあるようです。 skencil の場合には、setup.py に与えるパラメタを、下記のようにすれば良かったです。 ./setup.py install --dest-dir=%{buildroot} --prefix=%{_prefix} zope の場合には ./configure --no-compile と云うオプションがあります。 そしてインストール後に $INSTANCE/bin/compilezpy.py を実行します。

命名法は難しいなー PIL を VineSeed に上げるのに、勝手に python-Imaging と云う名前をでっち上げたのだけど、世間では python-imaging と云うじゃないですか。元もと野良ビルドで python-PIL なんて、何も考えないで付けていたのが遠因。確かに python-Imaging なんて名前は変ですね。そして斬られました;; パッケージ作成ポリシなどと云う哄笑なものを私が考えたのが間違い。python ライブラリの頭には "python-" と付けましょう、などと云うくらいしか頭になかった。元からあるパッケージ名が Imaging なのだから、プレフィックスを付けて、pythin-Imaging だろうと単細胞的な命名。じゃあ本当は Python Imaging Library のパッケージ名はどうすべきなのか。 バージョンの振り方についても Squeak などを考えると、頭が割れそうになるくらい難しいので止めて。たとえば COREBlog を例にしてみれば、バージョン 1.11 の次は 1.2 になってます。これはカンマを少数点と考えてると受け取れます。でも rpm の世界は逆 1.11 > 1.2 です。もちろん、パッケージングは、オリジナルに従属すべきもので、作者に意見を言うべき筋合ではありません。キッパリ。 とか考えてたら、python パッケージングポリシには命名法も必要なんだと、やっと今日解かりました。

python ライブラリのパッケージ作成ポリシーと spec template のセットみたいなものがあるといいかもしれませんね - と言われても、大御所が大勢居られる場に投稿する程の力量はありませんが、 誰かが進めないといけないと思ってるので、少し考えてみます。 python 関連パッケージングの原則は、下記の二つ 1) /usr/lib/python*/site-packages/ の下に入れるもの python ライブラリパッケージや、別ソフトのサブパッケージにかかわらず python の共有ライブラリ扱いは "python-" をプレフィックスとする。できれば、site-packages の下に単一ディレクトリを作りインストールすることが望ましい。 「独立アプリだけどそのライブラリが他から使われることも想定しているものがあったとすると 1) のほうにするという感じでしょうか」 はい、おっしゃる通りに考えてます。 2) 独立した python アプリは、たとえば /usr/lib 配下にまとめて入れるのが原則。 一般のパッケージで python ライブラリを提供するものも、自身のディレクトリ下に置く。 この場合 python ライブラリのバージョンをディレクトリパスなどで固定して指定しない。 一方、このライブラリを利用したい者は、自分でライブラリパスを設定し使用する。 この場合、python ライブラリのシンボリックリンクを参照するような方法でいけないのか考えてます。 python 本体や、関連パッケージが直接 /usr/lib/python*.* をリンクするように考えて作られているので、 少し調べないといけないと思ってます。この辺のことを解かってません。 例えば strings で *.pyc を見ると、ライブラリへのパスが見えるのですよね。 こんなことを考えた動機 1. python のマイナバージョンアップのたびに、関連するパッケージを調べないといけません。 そして一時に、スペック修正したり、リビルドするのは大変。 2. /usr/lib/python*.*/site-packages/ 以下が繁雑になってきたので、整理する必要があると考えた。 そう思うのなら提案すべき。 参考: http://www.python.jp/pipermail/python-ml-jp/2002-August/001762.html

最近 COREBlog ユーザが激増してるようです。 とりあえず Vine では Python/Zope 環境のベースは出来てると思いますが、python ライブラリのインストールで嵌まる話しをたまに見かけます。たとえば psycopg, pykf, kconv, PIL などですが。なので、必要な python ライブラリは VineSeed に上げることにしました。Zope のプロダクトに関しては、相変わらず、自分でどうぞと云うスタンスです。 とりあえず Zope と COREBlog を問題無くインストールでき、ZMI でプロダクト開発できる環境を作りたいなと思ってますが、今のままでは python ライブラリ関連が繁雑になりそうな気がしてます。整理する案を後で書きますので、よろしく御指導ください。