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を参照）。デーモン…
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は不要だ。