Bitcoin を GTK に変換：賛成？反対？wx の方が良い？
公式の Linux 版 Bitcoin クライアントを wx から GTK に変換できるスキルを持っている人はいるだろうか？
この開発は追求する価値や需要があるのか、それとも wx で問題ないのか？
質問：ちょっと待ってくれ。自分が望む変換に対して誰かが報奨金を出すのを求めているのか？（報奨金のアイデアは奇妙/変だと思われたため却下） 回答：自分が望んでいるわけではない。GTK は QT やその他のものより良いのか？よく分からない。
「Bitcoin が wxWidgets の代わりに GTK を使ってくれたら嬉しいが、その変更がどれほど難しいか簡単かについてまったく見当がつかないとは言わない」
誰か：wx は今のところ問題なく動いているように見える 別の誰か：wx は完全な悪夢だ
質問：なぜサトシのフロントエンドを「変換」するのか？RPC コールを使って新しいものを構築すればいいのでは？
実際、bitcoind のメソッドを GUI と同じことができるほど便利にするために必要なことはそれほど多くない： 特に：
- 送金アドレスの一覧表示
- listtransactions で未承認ブロックを表示する（おそらく）
- 表示するトランザクションの範囲を選択する
WxWidgets は実際には問題ではない。問題は使用されているバージョン（2.9）で、多くのディストリビューションパッケージャーは不安定だと見なしている（WxWidgets の開発者はそうではないと言っているが）。一方で、私の知る限り WxWidgets は Linux では gtk を使って描画しており、Bitcoin 開発者にとってクロスプラットフォーム対応を容易にしている。
theymos と同じく、GUI とデーモンは分離すべきだと思う（あるいはプロトコルなどをさまざまな言語のバインディング付きのライブラリにするとか）。自分の「クライアント」はすでに動いている（http://bitcointalk.org/index.php?topic=851.0 を参照）。デーモン（WxWidgets は不要）と一緒に非常にうまく動作する。だから、私の場合はもう WxWidgets への依存はない。
theymosと同じく、GUIとデーモンは分離すべきだと思う（あるいはプロトコルなどをさまざまな言語のバインディング付きのライブラリにするとか）。自分の「クライアント」はすでに動いている（http://bitcointalk.org/index.php?topic=851.0を参照）。デーモン (
http://bitcointalk.org/index.php?topic=851.0%E3%82%92%E5%8F%82%E7%85%A7%EF%BC%89%E3%80%82%E3%83%87%E3%83%BC%E3%83%A2%E3%83%B3)…
GUI とデーモンを分離すべきとはどういう意味だ？すでに分離されている。別のデーモンをビルドできる。GUI だけの別ビルドが必要なのか？なぜ必要なのか分からない。
GUI とデーモンを分離すべきとはどういう意味だ？すでに分離されている。別のデーモンをビルドできる。GUI だけの別ビルドが必要なのか？なぜ必要なのか分からない。
Bitcoin は P2P ネットワークなので、プログラムは常に動作している必要がある。しかし、GUI をずっと見ている必要はないのでデーモンがあると便利だ。現在、GUI 版を起動するにはデーモンを停止する必要があり、その間ネットワークが途切れる。
aMule のような P2P アプリケーションはこれを適切に行っている。デーモンが常に動作し、操作したい時に別の GUI を起動してデーモンに接続する。最も重要なのは、GUI はデーモンと異なるマシンで実行できることだ。
このようなセットアップはモバイルでの Bitcoin 利用に最適だろう。「サーバー」マシンでデーモンを動かし、モバイルデバイスの GUI から接続する。別の文脈で既に議論されたと思うが、同じメカニズムが適用される。
ただし、JSON-RPC メカニズムを使えば既に別の GUI を構築できるので、メインラインクライアントを変更する緊急の必要はない。
WxWidgets は実際には問題ではない。問題は使用されているバージョン（2.9）で、多くのディストリビューションパッケージャーは不安定だと見なしている（WxWidgets の開発者はそうではないと言っているが）。一方で、私の知る限り WxWidgets は Linux では gtk を使って描画しており、Bitcoin 開発者にとってクロスプラットフォーム対応を容易にしている。
wxWidgets 2.9 は彼らの最初の UTF-8 バージョンだ。我々は Windows 含むすべてのプラットフォームで UTF-8 を使用している。
ディストロの 2.8 パッケージは UTF-16 であるため、人々をつまずかせるだけだ。2.9 に標準化するまで、2.8 とその wxString UTF-16/ANSI 条件付きビルドオプションで終わりのないビルド問題があった。また、2.8 を使うために ANSI を使用していたが、これは wxWidgets が UTF-8 をサポートするまでの一時的な応急措置に過ぎなかった。
これは自然に解決する問題だ。時間が経てば、2.9 はより主流のリリースになるだろう。
teknohog が私の意見をこれ以上ないくらいうまく説明してくれた。
サトシ・ナカモトの投稿（2010年8月19日 18:44 UTC）BioMikeの投稿（2010年8月19日 08:05 UTC）WxWidgets自体は本当の問題ではない。私の問題は使われているバージョン（2.9）だ。多くのディストリのパッケージャーから不安定とみなされている（WxWidgetsの開発者はそうではないと言っているが）。一方で、私が知る限りWxWidgetsはLinux上ではgtkを使って描画しており、bitcoinの開発者にとってクロスプラットフォーム化を容易にしている。
wxWidgets 2.9は彼らが最初にUTF-8対応したバージョンだ。我々はWindowsを含む全プラットフォームでUTF-8だ。
2.8のディストリパッケージはUTF-16なので、人々を躓かせてしまうだけだ。2.9に標準化するまで、人々は2.8とそのwxString UTF-16/ANSI条件付きビルドオプションで延々とビルド問題に苦しんでいた。また2.8を使うために我々はANSIを使っていたが、これはwxWidgetsがUTF-8をサポートするまでの一時的な間に合わせに過ぎなかった。
これは時間が解決する問題だ。時間が経てば、2.9はより主流のリリースになっていく。
ええ、なぜ 2.9 が選ばれたかは理解している。それは妥当だとも思う。ただディストリから依存をインストールしたいだけの人にとっては不運というだけだ。（gentoo では、/usr/local に 2.9 をインストールしていると他の WxWidget アプリのビルドが壊れてしまう）
teknohogが私の意見をこれ以上ないくらいうまく説明してくれた。
サトシ・ナカモトの投稿（2010年8月19日 18:44 UTC）BioMikeの投稿（2010年8月19日 08:05 UTC）WxWidgets自体は本当の問題ではない。私の問題は使われているバージョン（2.9）だ。多くのディストリのパッケージャーから不安定とみなされている（WxWidgetsの開発者はそうではないと言っているが）。一方で、私が知る限りWxWidgetsはLinux上ではgtkを使って描画しており、bitcoinの開発者にとってクロスプラットフォーム化を容易にしている。
wxWidgets 2.9は彼らが最初にUTF-8対応したバージョンだ。我々はWindowsを含む全プラットフォームでUTF-8だ。
2.8のディストリパッケージはUTF-16なので、人々を躓かせてしまうだけだ。2.9に標準化するまで、人々は2.8とそのwxString UTF-16/ANSI条件付きビルドオプションで延々とビルド問題に苦しんでいた。また2.8を使うために我々はANSIを使っていたが、これはwxWidgetsがUTF-8をサポートするまでの一時的な間に合わせに過ぎなかった。
これは時間が解決する問題だ。時間が経てば、2.9はより主流のリリースになっていく。
ええ、なぜ2.9が選ばれたかは理解している。それは妥当だとも思う。ただディストリから依存をインストールしたいだけの人にとっては不運というだけだ。（gentooでは、/usr/localに2.9をインストールしていると他のWxWidgetアプリのビルドが壊れてしまう）
私にはこれこそ Bitcoin を Beta 状態のままにしておくのに十分な理由に思える。それが解決されるまで、つまり wx 2.9 がインストールしやすくなるか、Bitcoin が別のものへ移行するかのどちらかになるまで。
私にはこれこそ Bitcoin を Beta 状態のままにしておくのに十分な理由に思える。それが解決されるまで、つまり wx 2.9 がインストールしやすくなるか、Bitcoin が別のものへ移行するかのどちらかになるまで。
あるいは、デーモンだけビルドしてグラフィカル版はビルドしないというのもある。そうすれば WxWidgets は不要だ。