トップページ⇒tech
981コメント348KB

【GUI】wxWidgets(旧wxWindows) その3【サイザー】

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん2006/09/09(土) 00:06:30
クロスプラットフォーム GUI ライブラリの wxWidgets (旧 wxWindows)について語りましょう。

本家
　http://www.wxwidgets.org/
wxWindows日本語プロジェクト
　http://wxwindowsjp.sourceforge.jp/
Let's wxWidgets
http://dot-gray.s33.xrea.com/
(*)準備中(*)
http://www.geocities.co.jp/SiliconValley-Cupertino/8526/
wxWindowsで始めるC++ GUIプログラミング
http://www.h3.dion.ne.jp/~k5_n/wxwin/
wxWidgets でクロスプラットフォーム GUIアプリを作ろう
http://namazu.org/~satoru/pub/uu-2004-08/
dW : Linux : wxWindowsの概要
　http://www-6.ibm.com/jp/developerworks/linux/010413/j_l-wxwin.html
SunWorld Online：wxWindows――無名だが成熟したGUIツールキット
　http://www.idg.co.jp/sw/back/200102/20010219_01_report.html
0142デフォルトの名無しさん2007/03/04(日) 13:08:40
>>141
wxEvtHanderを継承してみました。

.hで
enum
{ SliderPage_Slider = 100, };

class SliderAndSpinCtrlSet: public wxBoxSizer, wxEvtHandler
{
public:
SliderAndSpinCtrlSet(wxWindow *parent, const wxString& title, int sliderID, float val, float min, float max, int spinCtrlID) : wxBoxSizer(wxHORIZONTAL)
{
m_slider = new wxSlider(parent, sliderID,
val, min, max ,
wxDefaultPosition, wxDefaultSize, 0);
m_spinctrl = new wxSpinCtrl(parent, spinCtrlID, wxString::Format(_T("%d"), val),
wxDefaultPosition, wxDefaultSize,
0,
min, max, val);
Add(m_spinctrl, 0, wxALL | wxGROW, 5);
Add(m_slider, 0, wxALL | wxGROW, 5);

}
void OnSlider(wxScrollEvent& event) { hogehoge... }
DECLARE_EVENT_TABLE()
};
として、.cppで
BEGIN_EVENT_TABLE(SliderAndSpinCtrlSet, wxEvtHander
EVT_COMMAND_SCROLL(SliderPage_Slider, SliderAndSpinCtrlSet::OnSlider)
END_EVENT_TABLE()
としてみましたが、コンパイルは通るものの、スライダーを動かしても何の反応もありません。
どうすればいいんだ・・・。Event Handling Overview今読んでいますが、難しいですね・・・。
0143デフォルトの名無しさん2007/03/05(月) 00:42:03
多分、コントロール自身かその親ウィンドウじゃないと、
コントロールからのイベントが到達しないんじゃない？
やっぱ、wxPanel継承して、そのハンドラで受けるのがいいと思う。
そのPanelをひとつのコンポーネントとしてとらえればいいわけだし、
他パネルに配置もできるでしょ？

どうしても嫌なら、wxEvtHandler継承で、
m_slider->Connect(
SliderPage_Slider,
wxEVT_COMMAND_SLIDER_UPDATED,
wxCommandEventHandler(SliderAndSpinCtrlSet::OnSlider),
NULL, this);
とすればできる気がする。動作確認してないけど。
0144デフォルトの名無しさん2007/03/05(月) 10:28:39
>>143
wxPanel継承でできました！ありがとうございます。
というかwxPanelをコンポーネントとして配置できる事を知りませんでした。
まだ使い始めたばかりなもので・・・。
0145デフォルトの名無しさん2007/03/08(木) 10:54:48
質問です。
ウィンドウを二つ表示しているんですが、
片方で何らかの操作をした結果の値を、もう一方のウィンドウ上に配置したスライダー
等のコンポーネントにリアルタイムに反映させたいのですが、何か方法はないでしょうか。

具体的に言うと、片方はwxGLCanvasを継承したクラスで、その画面上をドラッグすると
ある値が変わるのですが、ドラッグ中にもう一方のウィンドウ（wxPanel)上の
スライダー等の表示をその値を反映したものにリアルタイムに更新したいのです。

しかし、ドラッグ中にスライダー等にSetValueで値をセットしても、そのウィンドウに
フォーカスが移動するまでスライダー等の表示が更新されません。
仕方が無いのでドラッグ中にwxPanelのSetFocus()メソッドを呼んで無理やり更新させていますが、
なんか気持ち悪いです。

他に方法はないでしょうか。
0146デフォルトの名無しさん2007/03/08(木) 11:02:26
>>145
すみません。自己解決しました。
Update()関数で更新できました。お騒がせしました（汗）
0147デフォルトの名無しさん2007/03/10(土) 00:07:38
wxPanelのサイズを実行時に変更するにはどうしたらいいでしょうか？
0148デフォルトの名無しさん2007/03/10(土) 00:35:21
実行時に変更じゃわかんねーな
実行後に変更か？それともコンパイル時に指定か？
0149デフォルトの名無しさん2007/03/10(土) 00:41:52
コンパイル時ではなく，アプリケーションの実行時です．
読み込んだ画像の大きさに合わせて変更するような感じです．
言葉足らずですいません．．
0150デフォルトの名無しさん2007/03/10(土) 01:14:44
wxWindow::SetClientSizeかなあ
0151デフォルトの名無しさん2007/03/10(土) 01:15:07
wxImage image("foo.jpg");
panel->SetSize(image.GetWidth(), image.GetHeight());
みたいな感じでいいんじゃない？
0152デフォルトの名無しさん2007/03/18(日) 22:42:36
みなさん。
wxFrameにwxGLCanvasセットしているときって、
なぜかwxMessageBoxの表示が全面に出てこなくて、wxFrameを最小化するか、クイック起動の「デスクトップを表示」をするかしないと、
wxMessageBoxが現れなかったりしませんか？

ちなみに当方wxWidgets1.6.3使用。
1.8.2だと治ってるかなぁ・・・。
0153デフォルトの名無しさん2007/03/19(月) 08:48:42
>>152
2.8じゃなくて？
0154デフォルトの名無しさん2007/03/19(月) 09:16:38
>>153
そうでした。2.6.3使用で、2.8だと直ってるかな、でした。
0155デフォルトの名無しさん2007/03/29(木) 09:01:33
Mac の wxPython で使ってみてるんだけど、
wx.DC.GetTextExtent() がラテン文字以外は正しい幅を返してこないようだ。
Windows だとちゃんととれるのに。
これはどこの問題なんだ？
0156デフォルトの名無しさん2007/04/03(火) 17:10:57
wxWidgetsの問題．諦めよ．
0157デフォルトの名無しさん2007/04/03(火) 17:52:33
べつに諦めなくても自分で書いて送りつければいいんだけどね。
結構反応はやいよ。時々永遠に放置されるけどw

実装具合はポートによって様々。
一応実装されていても細かいところで違っていて、それを吸収する
クラスを書かないといけないこともある。
0158デフォルトの名無しさん2007/04/04(水) 16:41:07
http://groups.yahoo.co.jp/group/wxmljp/

日本語版メーリングリストが無いから作っといた
テンプレにいれといて
0159デフォルトの名無しさん2007/04/07(土) 00:08:15
なぁなぁ
wxWidgetsってさ、UTFの扱いどうなってるな？F8とか押すとさ、たまーにゴミ文字列
挿入されるんだがあれまじキレそうになるからなんとかしたいんだけど
どうすればいい？
0160デフォルトの名無しさん2007/04/07(土) 00:49:26
コンパイラをUnicodeにすればいいんでない？
0161デフォルトの名無しさん2007/04/07(土) 01:42:17
155だけど、日本語のフォントにしたら日本語についてはちゃんと取れた。
フォントのフォールバックが起こると取れなくなるみたい。
157のいう実装上の差異というところか。直せるのかな。
wxMAC のソースをちょっと覗いてみたら、元のAPIの仕様でそうなってるようにも見える。
Mac 詳しくないのでわかんないけど。

wxて Unicode や XML に詳しい人がコアにいないんじゃないかと思うことがある。
XRC の文法もなんか素人くさいよね。size をリテラルとして指定するとことか。
Uniscribe や TextLayoutManager（だっけ？）相当の機能がつくといいんだけどな。
ワイド文字列でコンパイルしただけじゃUnicode対応とはいえなかろう。

でも古典的な範囲でふつうに使ってる分にはやりやすい。嫌いなわけではないのよ。

あとインプットメソッドまわりは日本人がやらないと絶対始まらないと思うぞ。
0162デフォルトの名無しさん2007/04/07(土) 10:10:45
ソース見てきた。Unicode実装してない
嘘Unicode絶対間違って実装してるからバグバグになる。
最悪buffer overflowとかも平気でありありな実装で
こいつら死ねよって今からメール送りまくろうと思ってます。
メインの開発者全員にしねよねﾊｹﾞゴルァメールを送りつけて気を引き締めて
あげたいであります。
0163デフォルトの名無しさん2007/04/07(土) 23:49:22
>>162
そんなことよりパッチ送ってやれ。
どーせ理解できねーんだから。
0164デフォルトの名無しさん2007/04/08(日) 04:19:49
ソース見てないけど
Unicodeが問題になることといえばコードの上下関係だけじゃないの？
日本語をソートするとばらばらになるとかでしょ
基底はWindowsAPIをUnicode版に切り替えるだけだから切り替えミスでもしてない限りはOverFlowはないと思うけど
切り替えしてないならアフォだけど
LinuxとMacは単純にUnicodeAPIが無いから非対応という話ではないのか？
ちなみに一からlinuxやMacでUnicode作ろうと思ったら全部書き換えないと無理だろ
0165デフォルトの名無しさん2007/04/08(日) 07:36:26
>>164
>LinuxとMacは単純にUnicodeAPIが無い

UnicodeAPI って何だよw
もしかして Windows 以外では UTF-8 とか 16 とか弄れないと思ってるの?
0166デフォルトの名無しさん2007/04/08(日) 13:27:31
kernelレベルでデフォルトキャラセットをUnicodeにしないと無理でしょ
0167デフォルトの名無しさん2007/04/08(日) 14:31:15
ふぅん、カーネルレベルねぇ...
デフォルトキャラセットとな...
全部書き換えないと無理と...

Linux も Mac も使ったこと無いのに色々知ってるんだ
偉いねえ
0168デフォルトの名無しさん2007/04/08(日) 16:54:12
Unicodeはkernelレベルでサポートするべきものだったんだよ!
0169デフォルトの名無しさん2007/04/08(日) 16:55:32
な，なんだってーっ!
0170デフォルトの名無しさん2007/04/08(日) 17:47:29
>>168
当然そうあるべきだと思うが。
ファイルシステムやカーネルオブジェクト等に使われる名前の
エンコーディングに一貫性が無いとロクなことにならない。

名前のエンコーディングが不明では、文字列として正しく処理をしようが無い。
一方名前にエンコーディング情報も付与することにしたら無駄に
データ量が増えインタフェースも複雑化するだけ。

だから、Windows NTやPlan 9はUnicodeだよな。
Unixが時代遅れなだけ。
0171デフォルトの名無しさん2007/04/08(日) 17:59:31
一応書いておくと、カーネルモジュールでもファイルシステムとかは
Unicode 扱えないとちょっとダサイ。でもこれはユーザランドのアプリ
とは関係無い話。
01721712007/04/08(日) 18:04:28
ｽﾏﾝ。ボーッとしてたら被った。

>>170
"カーネルオブジェクト等に使われる名前" って何?
ASCII Code の範囲を超える文字を使うケースってあるの?

つか、カーネルモジュールで Unicode サポートが必要なのって
ファイルシステムだけだよね?　そして普通の Un*x なら kiconv
とか（似た様な名前の）機構が既に入ってるよね?

>>170 が時代遅れなだけ?
01731712007/04/08(日) 18:12:33
最後ちょっと下らない煽りっぽくなっちゃったが、カーネル内で実装されていようがいまいが、
ユーザランドのアプリで Unicode を使うには全く問題無いよ。全部書き換える必要なんて
全く無い。それと Mac も Linux もデフォで Unicode 使えるようになってるので、その意味
でも問題無い。
0174デフォルトの名無しさん2007/04/08(日) 18:35:28
いや別にネットからダウンロードしたUTF-8の文字をバッファにいれてカーネルEUCの状態で表示しようがしまいが勝手だし
そのためのクラス郡はwxWidgetsに用意されてるのだから好きにすればいいのでは？
今の話ってそういう話じゃないよね
Unicodeの入ったバッファの中身をEUCのAPIにパスして文字が化けるんですけどとかそういうこと言ってんでしょ？
そりゃ当たり前だって言ってるだけｗ
0175デフォルトの名無しさん2007/04/08(日) 18:40:56
strcpyとかstrlenとかAPIだよ
Unicodeの中身そのまま渡したらおかしくなるって
0176デフォルトの名無しさん2007/04/08(日) 18:42:08
>>174
>EUCのAPI

もっとくやしく。
0177デフォルトの名無しさん2007/04/08(日) 18:51:32
Windowsは２個用意してる
strcpyだとstrcpyAとstrcpyWと２種類のAPIが存在してコンパイルする時に何をベースにプログラムを動かすかで
自動的に切り替わるようになってる
linuxやMacはこういう機構が無いのだから完全にカーネル依存になる
基本的にカーネルの扱う文字コード以外ではコンパイルしてはいけない
別の文字コードを扱う時はバッファ内で変換してからすべての処理に引き渡すようにしないといけない
0178デフォルトの名無しさん2007/04/08(日) 19:26:12
>カーネル依存になる

だから、ならねっての。
C/C++ の標準ライブラリとカーネルの話をごっちゃにしてるね。
ついでに言うとロケールについても分かっちゃいない。
0179デフォルトの名無しさん2007/04/08(日) 19:40:11
kiconvって、kernel内部コードをUTF-8で統一
全てのシステムコールの界面でLC_CTYPEを使ってchar*のエンコード変換を
行うと解釈していいのかな？
それならWindowsの動作に近いんだが。

いや、kernel側にはユーザ側のLC_CTYPEは分からないか。
むしろシステムコールにラッパーかませるべき？どういう実装になってるの？
0180デフォルトの名無しさん2007/04/08(日) 19:44:56
話が全然噛み合ってねえな…
0181デフォルトの名無しさん2007/04/08(日) 19:45:09
>>177
> strcpyだとstrcpyAとstrcpyW
1. 存在しません。
2. strcpy()はWindows APIではなくC標準のランタイムライブラリです。
3. MSVC++はC標準ランタイムライブラリに対しても、TCHARベースの
　汎用テキストマッピングの仕掛けは提供しています。
　strcpy()の場合は、_tcscpy() -> strcpy() / wcscpy()です。
01821792007/04/08(日) 19:47:41
よくわからないんだけど。
kiconvってカーネルパッチでしょ？
コールゲート通過後の、カーネル空間に入っちゃったただのchar*のデータを
どうエンコード変換すべきか、どうやって判断してるんだ？

Windows APIの場合は、APIのレイヤで全部UTF-16にしてるよ。
その層だと判断できるし、カーネル内部がUTF-16に閉じてクリーンになるから。
0183デフォルトの名無しさん2007/04/08(日) 19:51:06
ネット斜め読みしただけで分かった風に書くなよ…
01841792007/04/08(日) 19:56:40
>>183
単純な話なんだから、分かってるのなら答えて欲しいんだけど。
・マルチユーザシステムであるUnixでは、ユーザ毎にLC_CTYPE設定が異なり得る。
　これが前提。
・何もしなければ（少なくとも昔のUnixでは）システムコールにchar*を渡せば
　それは「そのまま」kernelに素通しで渡るはず。つまり、一貫性の無い
　異なるエンコーディングの名前がkernelに渡されることになる。しかも
　kernelに渡ってしまった後はそのエンコーディングを判断するすべが無い。

　ユーザモードで呼ばれるシステムコールのCインタフェース（ラッパ）には
　呼び出し側プロセスの環境のLC_CTYPEが分かっているので、多分ロケールに
　従った変換をかけるならここがベストである、ように俺には見える。

で、
・↑のような変換を行うシステムコールラッパの仕掛けなんですか
・kernel内部はUTF-8で統一されているのですか
というのが質問。
間違っているのなら、どこがどう間違っているのか説明してほしい。
0185デフォルトの名無しさん2007/04/08(日) 20:09:41
>>184
何つーかさ、↓こういう質問が出る時点で答えるのを躊躇しちゃうのよ。

>・kernel内部はUTF-8で統一されているのですか

正直、君のレベルに合わせて回答を作るのは「単純な話」じゃないと思うよ。
誰にとっても。
01861792007/04/08(日) 20:13:21
>>185
>・kernel内部はUTF-8で統一されているのですか
なぜ、この疑問がそんなに問題なの？
Windows NTは、kernelが扱う「名前」「テキスト」は、全てUTF-16だよ。
kernelの扱う名前のエンコーディングに一貫性が無いと、例えばファイルシステム
のファイル名のエンコーディングが統一されていないと、問題でしょ？
UTF-16に統一することで、そのような問題を避けつつ、ASCIIよりはるかに
大きな文字集合を無問題に扱うことが出来ているわけ。
少なくともWindowsでは。

無論ファイルの中に入っていたりネットワークを流れるデータ（バイト列）の
具体的な中身にはkernelは関与しないよ。それはユーザレベルの話。
01871792007/04/08(日) 20:19:48
例えば

fd = creat(filename, 0666);
を実行した時に、

1) filenameはどこかでUTF-8に変換されますか
2) それはどこで行われますか
3) 変換されないならば、「全ての」ユーザコードが「各自」適切な
　エンコーディングを指定しない限り、
　ファイルシステムのエンコーディングの一貫性は保障されないということで
　良いですね。

ということなんだが。
0188デフォルトの名無しさん2007/04/08(日) 20:31:18
>>186
前にも書いたけどさ、符号化方式はファイルシステム固有の話であって
「カーネル内部で統一」という言い方はおかしいよね?
単に一個のカーネルモジュールに過ぎない訳だから。
君も一応マイクロカーネルな OS 使ってるんでしょ?

これはｵｹ?
01891792007/04/08(日) 20:52:19
>>188
・非Unicodeの符号化形式を採用しているファイルシステムは、それだけで
　i18n/m17n対応においてUnicodeベースのもの(FAT32やNTFS)より劣ると
　いわざるを得ないだろう。

・ファイルシステムが非Unicodeの符号化形式を用いている場合、ファイルシステムの
　モジュールなりドライバなりが、相互変換を行うべき。そしてその層に
　それが閉じているならば、カーネルとしてはUnicodeで考えることが出来るので
　「統一」と呼べるのでは。
　統一されていれば、異なるファイルシステム上の名前を比較したり、ファイル
　システム間で名前をコピーすることの問題も無くなるし、
　ユーザの実行環境のロケールが何であろうと、そのロケールとの相互変換を
　どこかのレイヤが行いさえすれば、問題なくファイル名を取り扱うことが出来る。

・今きづいたのだが、ファイルシステムの符号化形式との間の決めウチ変換を
　行うのがkiconvの役目？もしかして。
　だとすれば、それだけではWindowsの提供する環境より
　随分劣るといわざるを得ない。
0190デフォルトの名無しさん2007/04/08(日) 20:57:58
相変わらず、話が全然噛み合ってねえな…
01911792007/04/08(日) 21:10:05
>>187のような単純な質問には誰も答えてくれないの？

filenameの中身がUTF-8エンコードされていないなら、結局どうなるの？
1) EILSEQエラーなどではじかれる。
2) 普通にテキストと解釈できないへんな名前のファイルが出来る。
3) プロセス実行環境のLC_CTYPEに応じて、UTF-8に誰かが変換してくれる。
4) ファイルシステムに甚大な被害を及ぼす可能性がある。
0192デフォルトの名無しさん2007/04/08(日) 21:14:45
>>191
何答えても屁理屈こねられそうだからみんな嫌がってんだよ。
0193デフォルトの名無しさん2007/04/08(日) 21:15:33
>>187
1. いいえ
3. はい
0194デフォルトの名無しさん2007/04/08(日) 21:16:49
>>191
2
0195デフォルトの名無しさん2007/04/08(日) 21:17:24
↓勝ち誇った書き込みｷﾀｰ
01961792007/04/08(日) 21:19:08
>>192
具体的に俺の「どの」発言が屁理屈なの。
誤っている箇所があるなら指摘してくれよ。

俺はそもそも屁理屈をこねるほど最近のLinuxのことを知らないから、
聞いてるだけなんだが。
0197デフォルトの名無しさん2007/04/08(日) 21:21:54
>>196
↓これ

>>189
>・ファイルシステムが非Unicodeの符号化形式を用いている場合、ファイルシステムの
>　モジュールなりドライバなりが、相互変換を行うべき。そしてその層に
>　それが閉じているならば、カーネルとしてはUnicodeで考えることが出来るので
>　「統一」と呼べるのでは。
>　統一されていれば、異なるファイルシステム上の名前を比較したり、ファイル
>　システム間で名前をコピーすることの問題も無くなるし、
>　ユーザの実行環境のロケールが何であろうと、そのロケールとの相互変換を
>　どこかのレイヤが行いさえすれば、問題なくファイル名を取り扱うことが出来る。
01981792007/04/08(日) 21:22:24
>>193, 194
教えてくれてあんがと。
んじゃ、問題ないとか言い切ってる>>171は勇み足さんかな。

事実上そのUTF-8対応したLinuxとそうでない従来型ロケールベースでは
運用方法から何から全然変わってこない？
皆が皆UTF-8に移行してるわけじゃないでしょ？

どっちでも動くプログラムとか書くの、面倒じゃないの？
0199デフォルトの名無しさん2007/04/08(日) 21:25:00
>>198
>>>171は勇み足さんかな。

勝手にあんたの持論に巻き込むな。
0200デフォルトの名無しさん2007/04/08(日) 21:31:09
>>198
>事実上そのUTF-8対応したLinuxとそうでない従来型ロケールベースでは
>運用方法から何から全然変わってこない？

誰か俺にも分かるように翻訳してくれ。
02011792007/04/08(日) 21:42:51
>>200
非UTF-8カーネルでユーザ毎にLC_CTYPEが異なる昔ながらのL10N環境と、
カーネルからユーザロケールまでUTF-8を前提とした環境と、
UTF-8カーネルに従来型ロケールの環境では、
ユーザコードでiconv()やwcstombs()等を用いた変換が必要な箇所が
変わってくるんでは？と思ったんだけど。

気のせいだというのならいい。
02021792007/04/08(日) 21:43:50
>>197
えーと、俺は見ての通り頭が悪いし最近のLinuxのことは知らないので、
誤りはもっとピンポイントかつ具体的に指摘してくれると嬉しいのですが。
0203デフォルトの名無しさん2007/04/08(日) 21:54:41
>>202
> 誤りはもっとピンポイントかつ具体的に指摘してくれると嬉しいのですが。
スレ違い
0204デフォルトの名無しさん2007/04/08(日) 23:46:39
よくある逃げ方だな。
ごくろーさんｗ
0205デフォルトの名無しさん2007/04/08(日) 23:52:15
↑捨て台詞ｷﾀｰ
02061792007/04/09(月) 00:00:11
>>204は俺ではないですよ。どうでもよいことですが。
0207デフォルトの名無しさん2007/04/09(月) 00:54:49
で結局
EUCベースのlinuxでwxWidgetsでUTF-8を用いたアプリを開発するにはどうすればよいかという話でしょ

１．wxWidgetsが馬鹿なので書き換える
２．アプリをEUCで作る
３．linuxをUTF-8に対応させる

さあどれだｗ
0208デフォルトの名無しさん2007/04/09(月) 00:57:38
話の発端はwxMACだっけ
ということはMACのカーネルは何のコードがデフォなんだ？
0209デフォルトの名無しさん2007/04/09(月) 01:32:03
わかってもいないし調べる気もない奴らばっかだということはよくわかったから
もうここで続けるな。どこか他所でやってくれよ。
0210デフォルトの名無しさん2007/04/09(月) 01:55:55
>>193-194を見る限り、
$ touch ほげ
とかやった場合、要するにロケール設定によって全然別の名前のファイルが
作られるわけか？
なんかもう脳死してるっていうか、どうしようもないんじゃねぇのこれ
0211デフォルトの名無しさん2007/04/09(月) 02:04:26
wow　wxWidgetsの話はどこに行ったのさ？
0212デフォルトの名無しさん2007/04/09(月) 02:04:34
つか、非ASCII文字を含むファイル名を表示するまともな方法、存在すんのか？
ほげ：sjis
ほげ：euc-jp
ほげ：utf-8
みたいなファイル名が混在し得るんでしょ？
一つのファイルシステムに。
0213デフォルトの名無しさん2007/04/09(月) 02:28:20
>>211
readdir()やftsを使ってで読み取ったファイル名のリスト
をリストボックスか何かに表示したいです。
どうするのが正しいのでしょうか。
0214デフォルトの名無しさん2007/04/09(月) 02:41:11
WindowsだってeucとかUTF-8のファイル作ろうと思えば作れる罠
0215デフォルトの名無しさん2007/04/09(月) 02:45:52
リストボックスは当然ながらKDEとかGNOME依存でこれらは結局kernelの文字コードにあわしてある
kernelがEUCなら当然XシステムもEUCでフォントデータベースもEUCだからEUCのフォントインデックスじゃないと
いわゆる文字化けした状態になる
0216デフォルトの名無しさん2007/04/09(月) 02:56:42
>>215
> kernelの文字コード
> kernelがEUCなら

いみが
わかりません。

Linuxでは、文字エンコーディングを指定してカーネルを再構築するのでしょうか？
それによって、具体的にkernelの何が変わるのですか？
Unixはマルチユーザシステムですが、他のLocale設定を使いたいユーザは
どうすればよいのでしょうか？
0217デフォルトの名無しさん2007/04/09(月) 03:06:44
>>214
「やろうと思えば出来る」のと、「通常の使用でそういう事故が起きる」
のとでは、当然ながら全然違うんだが。

WindowsのコードページはUnixのロケールほど揮発性でも動的でもないし、
むしろ日本語Windowsなら実質CP932決めウチ、みたいな世界だ。
そしてAnsi版APIは、APIレベルでUTF-16への変換を試みるから、そこで
妙な名前はガードされる。
Unicode版APIは素通しだけどな。CreateFileW()にUTF-16として
正しくない並びの文字列を渡してもそのファイルを作れてしまうのは確か。
ただし、「ユーザが」「普通に」使用していてそういう事態に陥ることは
まずない。
0218デフォルトの名無しさん2007/04/09(月) 03:55:56
>>215
もうそのネタを引っ張るのは無理でしょ。流石にフォントの並びは変わらねえw
「カーネルの文字コード」という概念は個人的に破壊力抜群だったけどww
「EUC ベースの Linux」は後々まで語り継がれる名言だったなwww

釣り、なんだよね?
0219デフォルトの名無しさん2007/04/09(月) 04:06:30
また過去においては Linux の C Library にはロケール機構の実装は行われて
おらず X Window System の提供するロケール機構を使用していた。近年になっ
て X のロケールから GNU C Library version 2 に実装されたロケールへの移
行が進んでいる。残念ながら現時点では日本語をはじめとする多バイト文字の
ロケール機構は機能していないが実装作業が進行中であり、近日中に利用可能
になるものと思われる。
0220デフォルトの名無しさん2007/04/09(月) 04:20:33
>>210,>>212,>>217
Windows だって一緒やがな。メールに添付されたファイルのファイル名が EUC-JP
だったら誰が valid なファイル名を探してくれるのでしょうね。zip に入っていたファイルの
ファイル名が UTF-16 のエンディアン違いだったらどうするのかな?

スレ違いなんで↓続きはこっちでやってね。

文字コード総合スレ part2
http://pc11.2ch.net/test/read.cgi/tech/1143375639/

>>219
残念ながらそのネタも面白くないと思われるよ。
0221デフォルトの名無しさん2007/04/09(月) 04:49:56
>>220
ちゃんと規格確認してから言ってる?
特定の実装の問題を全体に拡大解釈するなよ
0222デフォルトの名無しさん2007/04/09(月) 05:18:41
>>221
規格って、zip に入れるファイル名の文字コードの規格があるの?
特定の実装って何の実装の事?

実際には Linux だってわざわざファイル名に複数の文字コードを混在させて使おうと
する人間はいない。混在可能ってだけだし、それは Windows でも一緒。
0223デフォルトの名無しさん2007/04/09(月) 05:35:45
知識自慢ばっかで解決策を語れるスマートな人間はまったくいないな
wxWidgetsのソースをいじるなんてのは非現実的だし
ロケールをわざわざUnicodeに変換したって既存のソフトが動かなくなるだけ
答えは１つ、デフォルトロケールにアプリを合わせて自前でコード変換するだけ
それ以外の方法はない
それ以外の方法しか考えられないやつはただの馬鹿
0224デフォルトの名無しさん2007/04/09(月) 05:38:24
知識自慢というか、正しい認識を持つことは重要だよ。
で、何の解決策が必要なんだっけ?
0225デフォルトの名無しさん2007/04/09(月) 06:06:24
ボケ老人は無理して話に加わらなくていいのに・・・。
0226デフォルトの名無しさん2007/04/09(月) 06:51:00
> zip に入れるファイル名の文字コードの規格があるの?
zip に入れるファイル名の文字コードの規格はないの?
0227デフォルトの名無しさん2007/04/09(月) 07:26:40
無い
0228デフォルトの名無しさん2007/04/09(月) 08:08:56
無いよなぁ…
0229デフォルトの名無しさん2007/04/09(月) 08:11:09
>>223
>wxWidgetsのソースをいじるなんてのは非現実的だし

ノンサポートのライブラリなんだから、きちんと全容を把握して
自分で手を入れられるようになっておいた方が良いぜ。
0230デフォルトの名無しさん2007/04/09(月) 08:54:57
>>223
オープンソースなんだし常識じゃないの？
カーネルのソースも、wxWidgetsのソースも動作がおかしい場合は、
読んで修正しないとねぇ。
0231デフォルトの名無しさん2007/04/09(月) 12:06:11
>>220
あのさぁ。メールの添付ファイルだのzipアーカイブの中身だのに含まれる
ファイル名をどうシステムのファイル名にマップするかってのは、
そのプロトコルなりRFCなりファイルフォーマットなりの話であって
OSの仕事ではないでしょ？
そこに不備があるのなら、それはOSでなくて、符号化形式が
self-containedではないそれらの不備ってだけだろ？
0232デフォルトの名無しさん2007/04/09(月) 12:08:37
少なくともWindowsでは
単にシェルでファイルをとりあつかうだけのことで問題が生じることは無い。
ファイル名はUTF-16「である」のがWindowsだ。
Windowsのファイル名はコードページに依存しないし、コードページによらず
漢字や拡張ラテン文字を含むファイル名を同時に正しく扱える。

Linuxでは
$ >ほげ
とかやるとどうなるんだっけ？
0233デフォルトの名無しさん2007/04/09(月) 12:36:11
スレ違いage
0234デフォルトの名無しさん2007/04/09(月) 13:32:49
結局、>>213の答えは？
0235デフォルトの名無しさん2007/04/09(月) 13:38:35
>>229
入れられるのと実際に入れるのとでは意味が違う
手を加えたらパッチが当たった時にまたそれに合わせて全部拾い出していくのか？
よっぽど暇なんですね
0236デフォルトの名無しさん2007/04/09(月) 13:41:47
せっかくクロスプラットフォームで多くのチェックが入ってバランス統一されたものに
わざわざ手を加えてクロスプラットフォームじゃなくならせるなんてよっぽど馬鹿なんですね
0237デフォルトの名無しさん2007/04/09(月) 17:45:41
>>234
見ればわかると思うけど、ここ能無ししかいないから
誰も答えられません。
0238デフォルトの名無しさん2007/04/09(月) 18:26:14
じゃあお前が答えろよｗ
0239デフォルトの名無しさん2007/04/09(月) 18:34:55
知識が無いことより、分かっている振りをすることのほうがはるかに馬鹿な事なのに
プログラマはそれがわからない馬鹿が多くて本当に嫌な人種だな
むしろ人間じゃねーな
0240デフォルトの名無しさん2007/04/09(月) 20:18:26
>>231
そこまで書いたら自分で気付けよw
0241デフォルトの名無しさん2007/04/09(月) 21:49:34
>>240
要するに、Windowsのファイル名はUTF-16固定だが
Unixのファイル名のエンコーディングに関しては、規約も標準も
何も無い無法地帯で、かつシステムグローバルでも何でもないLC_CTYPE
環境変数の設定でエンコーディングがころころ変わってしまい、
結果としてプログラム的にどうあるべき、という正しい判断のしようが無いから
糞なんだろ？

どこが「Windowsも同じ」なの？
Zipのようなファイル形式で困ったことになる点だけは確かに同じだな。
だが、それはOSの問題ではないし、論点ずらしだろ。
■ このスレッドは過去ログ倉庫に格納されています