プロプラな商品の方は、少なくともPyQtでは可能のようです。
(PyQtの)FAQによれば、
> "PyQt and SIP are available under the GNU GPL and a commercial
> license, very similar to the way in which Trolltech licenses Qt."
とのことなので。ただ、他のは無理そうですねえ。
#その手の要望が増えれば、PyQtのようなものが
#他の言語でも出てくる可能性はあると思います。
GUI toolkit 多すぎ!! (スコア:0)
Re:GUI toolkit 多すぎ!! (スコア:0)
にも関わらず、なぜATOKXやWnn7はGTK+を採用してるのでしょうね…
Re:GUI toolkit 多すぎ!! (スコア:3, 興味深い)
既に理由は出揃っているようですが、Qt の問題は、
に尽きるのではないでしょうか? Windows 方面であれば C++ 拒否反応もまだ小さいでしょうが、gcc
Re:GUI toolkit 多すぎ!! (スコア:1)
PyQt [riverbankcomputing.co.uk]やPerlQt [sourceforge.net]やQt# [sourceforge.net]
やRuby/Qt [u-shizuoka-ken.ac.jp]等(ここ [kde.org]も参照)では
なにか不都合があるのでしょうか?
Re:GUI toolkit 多すぎ!! (スコア:1)
「C++ でしか使えない」という言葉の上では仰る通りで 「C++ を経由しないと使えない」と言うべきかも知れません (こちらこそ解釈が違っていたら申し訳ありません)。
Perl なり Python なり (他も同様) と libqt で ATOKX や Wnn が書けて、 しかも使用した g++ に依存しないバイナリが生成できて、 かつ、プロプラな商品にできるのであれば特に問題なかったのではないかと思います。
これらの language binding を実際に利用したことがないので確信が持てないのですが、 g++ 依存性の問題は回避できるのでしょうか? (それ以前にプロプラな商品にできそうにありませんが...)
Re:GUI toolkit 多すぎ!! (スコア:1)
いくつか解釈が考えられたものですから、あのような書き方になってしまいました。
読み返してみると、煽っているように読めますね。お詫びいたします。
#質問を投げかけたつもりだったのですが・・・
g++依存の問題は、私の理解ではQtをどう扱うかに依存している問題で、
Qt自体がg++以外でもコンパイルできたような記憶があるので
staticで使えればなんとかなるかと思いますが、普通にsharedライブラリ
としてQtを使うとなると、実際問題としてはg++に依存せざるをえないと思います。
プロプラな商品の方は、少なくともPyQtでは可能のようです。
(PyQtの)FAQによれば、
> "PyQt and SIP are available under the GNU GPL and a commercial
> license, very similar to the way in which Trolltech licenses Qt."
とのことなので。ただ、他のは無理そうですねえ。
#その手の要望が増えれば、PyQtのようなものが
#他の言語でも出てくる可能性はあると思います。
Re:GUI toolkit 多すぎ!! (スコア:0)
# 罵声なのでAC