Mac OS XでもGTK+ 99
ストーリー by Oliver
GUIもSwitch 部門より
GUIもSwitch 部門より
bluedwarf 曰く、 "本家より、Linuxでよく使われるGUIライブラリGTK+のMac OS X AquaポートGTK+OSXがバージョン0.1のアルファ版としてリリースされた。これは、GTK+を使用したプログラムをXDarwinなどのX Windowシステムを介さずに、ネイティブのAquaインターフェースを利用して実行するためのライブラリだ。
現在、X Windowシステム上で動作する多くのアプリケーションがGTK+で書かれていることを考えると、非常に多くのX WindowアプリケーションがMac OS Xでネイティブアプリケーションとして動作させることができるようになるかもしれない。特にGTK+のきっかけとなったThe GIMPがネイティブで動作することに期待したい。
必ずしもGTK+のツールキットがAquaインターフェースと一対一に対応するわけではないので、そう簡単に移植ができるわけではないだろうが、そこのところをどう対応させるかも注目すべき点だ。"
先例で占おう… (スコア:3, 参考になる)
>非常に多くのX WindowアプリケーションがMac OS Xでネイティブアプリケーションとして動作させることができるようになるかもしれない。
GTK+とかって、Winには随分前から移植済み、でしたよねえ。
で、Winにおいて、Xの(という言い方が妥当かどうか気になるが)アプリが
そんなに「沢山」移植されたんでしたっけ?
先例が、MacOSで今後何が起きるか、を占うネタに少しはなりますかね。
#占って益が有るかどうかは別問題なのでG7
まだ占えない (スコア:3, 参考になる)
# 今年こそはえせcomitterに成り上がらねば…
まず、G7さんの「Windowsという先例を見てみよう」という発想は、とてもまっとうなものであると自分も感じますし、現状ではたくさんのアプリが移植・活用されていないという見方にも同意します。
しかし、
> GTK+とかって、Winには随分前から移植済み
という前提は、非常に疑わしいものだと思います。
確かに1.3の頃に、「次はWindowsに移植だ~」という話はありましたが、その成果である2.0のリリースノート [gtk.org]には、
「Previews」とか、「A final version of the Windows port is expected within a month or two.」
という弱気な言葉が並んでいました(実際使ってみても、安定しているとは言い難いものでした)。その後も、開発者側から正式な完成宣言は出ていないはずです。
2.0系列のbugfixリリースでは度々、Windows周りで「improve」「fix」の文字が並び、先日リリースされた2.2.0 [gnome.org]で、ようやく
「substantially complete」
という表現にまでなりました(僕はまだ実際に試していません)。
ということで、「従来のGTKのWindows portは完成度が低かったので普及しようがなかった」というのも一面であると、自分は思っています。
(それでも、自分一人にかかる負担の割合がとても大きい中、彼 [gimp.org]はかなりよくやってると思います)
あとは、文化の違いもあるでしょう。
現状では、「公式バイナリ」というものがあまりビシッとありませんよね。しかしWindowsユーザはこれがないと当然、受けつけないのではないでしょうか。
自分の結論は、「まだ占えない」です。
Re:先例で占おう… (スコア:2, 参考になる)
未だに Xt + Xaw でちょこちょこ小物を書いたりする人が言うのもナンですが。
GTK+「だけ」でアプリケーションが書けるのであれば別ですが、なんだかんだ unistd.h やらを #include したりすることが多かったりしませんか? Qt にしても同じで、Windows モノと本当に互換に作ろうとすると、Qt + ISO-C++ で書くことになる (VC++ の ISO 準拠度についてはここでは論じないものとしませう :-) わけですが、素人目で見る限り、そうそう簡単なことではないと思います。
I18N なコードがなかなか増えない事から察するに、理論上 Win/Unices 互換なコードが書ける事が即ち Win/Unices 互換なコードが増えることに直結するとは思いません (労力の節減にはつながるので歓迎はしますが)。
# なんだかんだで嫌いではあるけれど、現状では
# Java 使うのが最短距離のような気がする。
Re:先例で占おう… (スコア:1)
MFCとは目的が違うし、libcの役割まで要求するのはナンセンス。
# rm -rf ./.
Re:先例で占おう… (スコア:1)
つまり、元コメントは「GUI toolkitだけが互換になっても、libcあたりが互換でないと互換ソフトは生まれにくい」って言ってるわけだが。
Re:先例で占おう… (スコア:1)
たとえば、unistdな関数って存在しなかったりするでしょ。
お行儀良くANSIな関数だけで書いてあるプログラムなら、あるいはうまく行くでしょうけど、それはいろいろ困難なわけでして。
> autoconfとかって何のためにあるの?っつー話もありますよねぇ。
根本のところがわかってらっしゃらないようですね。
autoconfは魔法の杖じゃないですよ。原理や使い方を見たらわかると思いますけどね。autoconfは「互換性を考慮したプログラムを書く手段」ではありますが、「それを使えば互換性はバッチリ」というものではありませんよ。
Re:先例で占おう… (スコア:1)
そこまでわかってるんだったら、ますます元の意味の取り違いかと。
「UNIX同士ですら、こういうものが必要なレベルでの互換性でしかない。だったら、Windowsにtoolkitが移植されてもその互換性ってあんまり役に立たない」とは思わないです?
> 「このソースはLinuxで動いてるから、UNIX全般で動くはずだ」
そーゆー人には、黙ってemacsのコードでも読ませてあげればそれで十分かと。論より証拠ですよ。
占うには不十分すぎるネタ (スコア:1)
2) Mac OS (X)で動作するアプリケーションは優れたものである程、シェアウェアであるという傾向が強い
3) そもそも、Mac OS XがUnixベースである
などなど。
Windowsなんかを、「MacOSで今後何が起きるか」、を占うネタにする前に、まずこういった点を占うネタにしてくださいませ。
// Give me chocolates!
Re:占うには不十分すぎるネタ (スコア:1)
>3) そもそも、Mac OS XがUnixベースである
ところで、そもそもこの2点なのですが、我々(^^;の願望としては、
互いに相反する点であって欲しい、という気がしちゃいます。
Unixベースなのにシェアウェア(てゆーか、それって恐らく多くはClosedSourceなのですよね?)って、
なんか違うべやって感じ…(T_T)
#ObjectiveCやInterfaceBuilderの世界になら行ってみたいのでG7
Re:占うには不十分すぎるネタ (スコア:1)
なにが灸だよ…
#馬鹿らしいのでG7
Re:先例で占おう… (スコア:1)
そのことも含めた先例としてwin版が存在するよね、という話。
先例があるってことは、原因を分析「しなくても」現象を観測できる、ということです。
#もちろん、分析「するな」などと言ってるわけではないです(^^;。
移植していただきたい? (スコア:1)
と、希望だけ述べてみる。
はすかわ
Re:先例で占おう… (スコア:1)
自分で調べたついでに (スコア:1)
Re:先例で占おう… (スコア:1)
ところで、どんなメリットが激減するんでしょうか?
日々cygwinをにこにこして使ってる俺(藁)は、気付かぬうちに大損してるんでしょうか?(^^;
cygwinで有ろうが無かろうが、Win独自の便利(?)な仕掛各種が「GTK+から」使えない、のは同じですよね。
#Win用に「拡張」したGTK+を作ることは可能だとしても、移植性を考える場合にはそれは無意味だし。
-----
ついでにところで、
>パッケージも作らなきゃ行けない、GTK+にも変種が幾つかあるから、
>どれを使えばいいかとか、自前でGTK+をもってしまうだとか、いまいちメリットがない。というのがWin32の現状。
という部分は、
>OSXはベースのDarwin環境が十分にUNIXなんで、そのへんの心配は些細です。
OSXがUNIXかどうかとは、無関係ですよね?
#「まだ」変種が無い、という話なら判るが。
#てゆーかOpenSourceなんだから"多様性は善"なのでわ(^^;;;;;
一対一対応? (スコア:1, 参考になる)
GTK+はその下のレイヤのGDKレベルでターゲットに移植されていて、GUI部品はGDKを使ってレンダリングやイベント取得などを行うので、GDKさえ移植されてしまえば(もちろんGLibやPangoも必要だけど)、常識的なGTK+アプリケーションはすんなり移植できるはず。
移植出来ないとすればGTK+以外の部分で引っかかってるということでしょ(UNIXのAPIが揃ってないとか、直接Xを呼び出してたとか、autoconfが走らんとか)。
Re:一対一対応? (スコア:1, すばらしい洞察)
Re:GUI toolkit 多すぎ!! (スコア:1, 興味深い)
「Linux ディストリ多すぎ。全部 Vine に統一してほしい」
「BSD 多すぎ。全部 NetBSD に統一してほしい」
...のあたりはぜんぶ「フレームのもと」でしょうが...
「次期記録メディア多すぎ。なんでもいいから、全部なにかひとつに統一してほしい」
...とかだったら、みんなそう思ってるんじゃないかな。
オフトピ進行(Was:GUI toolkit 多すぎ!! (スコア:3, おもしろおかしい)
>
>...とかだったら、みんなそう思ってるんじゃないかな。
そこまでは賛成ですが、「何に?」となると、全員で「今、私が使っているものに!」と言い出すに3アレゲ
Copyright (c) 2001-2014 Parsley, All rights reserved.
Re:GUI toolkit 多すぎ!! (スコア:2, すばらしい洞察)
Re:GUI toolkit 多すぎ!! (スコア:2, すばらしい洞察)
ソフトウェア開発会社が壊滅します(w
運用やサポート会社は儲かるかもしれないが。
by rti.
Re:GUI toolkit 多すぎ!! (スコア:1, すばらしい洞察)
国多すぎ (スコア:1, おもしろおかしい)
「宗教多すぎ。全部イスラム教に統一して欲しい」 by 或る甲斐だ
なんてのは? 同意が得られそう?
マジレス禁止。マイナスモデされるよ。
Re:GUI toolkit 多すぎ!! (スコア:1, 参考になる)
とてもじゃありませんが、Windows用やMac用のQtは買えません。
Gtkに頑張ってホスイ。
Re:GUI toolkit 多すぎ!! (スコア:2, 参考になる)
(たぶん関連してますが)SourceForge.netにもプロジェクト [sourceforge.net]が存在しています。
Re:GUI toolkit 多すぎ!! (スコア:1)
袋叩きにされるかなとか思ってみるテスト。
by rti.
Re:GUI toolkit 多すぎ!! (スコア:1)
別に袋叩きにはならないと思いますが、Windows 用のバイナリを生成できるフリーで便利な開発環境って何があるでしょう?
ぱっと思いつくのは Borland や Digital Mars のコンパイラですが、「コレがある!」という情報のお持ちの方はポインタ提示お願いします。
Re:GUI toolkit 多すぎ!! (スコア:1)
配布パッケージのサイズは小さいし、統合環境あるしで
悪くはないと思いますが。
Re:GUI toolkit 多すぎ!! (スコア:1)
C/C++ を使う場合は mingw になるようですね (Perl/Python/Ruby も使えるのに C に分類する vector.co.jp はどうかと思わなくもないが、それは別の話)。 自前の class library も持ってるみたいですので少し大変そうですが、今週使って試してみます。
統一と多様性 (スコア:3, おもしろおかしい)
Re:GUI toolkit 多すぎ!! (スコア:2, 興味深い)
Re:GUI toolkit 多すぎ!! (スコア:2, 興味深い)
僕ならば、オープンソースの世界に限れば、雑に「良い」と言ってしまいたくなります。
ハードウェアの世界では、その「多様」の選択に伴って、ユーザの蓄積したデータの互換性を保つコストが馬鹿にならない(あるいはほぼ不可能)という点で、ある意味別モノではないでしょうか。
Re:GUI toolkit 多すぎ!! (スコア:5, すばらしい洞察)
たとえば、Xの実装にはXFreeがあったりAccXがあったりと多様ですが、これらはXプロトコルという共通のAPIを持ち、それらを入れ替えてもその上で動作するウィンドウマネージャやアプリケーションには影響を与えません(もちろん速度とか微妙なタイミングが問題な場合は多少あるでしょうが)。
ウィンドウマネージャも(gnomeやKDEとかの話は置いとくと)twmだろうとIceWMだろうとsawfishだろうと、これらを入れ替えても同じアプリケーションを使えます。
X以外でも、たとえばwu-ftpdとProftpdを入れ替えても、同じFTPというサービスをユーザに提供できます。
こういう上位層との間に標準的なAPIがあり、他の物と入れ替えても上位層に影響を与えないようなものや、上位層が他のプログラムではなく人間であるアプリケーションであれば、手放しに「多様線は善である」と言ってもいいかもしれません。
しかし、toolkitとかgnome/KDEといった、お互いに差し替えが(簡単には)できないものの場合は無邪気に「多様性は善である」とか言ってられないのではないでしょうか?
toolkitのように、複数のtoolkitを使ったアプリケーションを同時に動作させる事ができるような場合はまだマシですが、gnomeとKDEのように排他的であって、なおかつ、どちらかの環境でないと動作しないようなものがある場合は「多様性は悪」となる事もあり得ると思います。
商用Unixの失敗(と、あえて書くけど)の原因は、一見多様性があるように見えて、実はメーカによる囲い込みが行われているだけで、「たくさんあるけど互換ではない」ためだったのではないかと思います。
その同じ轍を踏まないためにも、「多様性」には慎重であるべき場合もあるのではないでしょうか?
これは単純に「どれか一つに決めて他は捨ててしまえ」と言うのではなく、たとえば上位層とのAPIを共通化するとか、ソースレベルでの互換性を持たせるなどの方法で「多様性を維持しつつ共通化、互換化する」というのは可能だと思います。
もちろん、こういう共通化には多大な努力が必要でしょうが、それをしないままに「多様性は善である」とばかりにforkを続けるというのはマズいんじゃないかな?と思います。
Re:GUI toolkit 多すぎ!! (スコア:3, 参考になる)
「硬直」「老化」ということが起きなければね。
> 商用Unixの失敗(と、あえて書くけど)の原因は、一見多様性があるように見えて、実はメーカによる囲い込みが行われているだけで、「たくさんあるけど互換ではない」ためだったのではないかと思います。
> その同じ轍を踏まないためにも、「多様性」には慎重であるべき場合もあるのではないでしょうか?
確かに不便ではありましたが、UNIXが絶滅しないで済みました。あの互換性のないメーカ性UNIXがいくつもあったお陰で、全てがWindowsになってしまうということはありませでした。そりゃ互換性があればもっと良かったということは同意しますが、単純に多様性があっただけでも、そういったメリットがあったのです。
Re:GUI toolkit 多すぎ!! (スコア:1)
もちろんあればあったに越したことはないけれど、なくても多様化している方がrobustであると。
Re:GUI toolkit 多すぎ!! (スコア:1)
だから、ちゃうって。
統一されていようがいなかろうが、とにかくあっちこっちからいろいろ出てたから、生き残るものも出たってこと。種が多様化すると絶滅しにくいとかって生物学であるでしょ。
Re:GUI toolkit 多すぎ!! (スコア:1)
互換性を重視することのデメリット:
そもそもプロダクトの進化には互換性の切り捨ては表裏一体なことは Windows や MacOS を見ても経営者にとっては常識なんだろうし、そう考えると互換性ばかり見ていなかったことが生き残りの要因になったのはとても鋭い意見だと思うなあ。
あと、統一された唯一のものしかなかったら、というのはあくまで仮定の話なので、それに固執しても意味はなさない気がする。そのせいで話がずれてるし。
それから、蛇足だけど「わかってない/読めてない」と他人に安易に言い過ぎるのはやめた方がいい。見ていて気取りが鼻につくし、無駄なフレームの元だから。
#フレームこそ我が命、という方はその限りではありません。
Re:GUI toolkit 多すぎ!! (スコア:1)
#読めてないのはお前だ、というあなた。正しいです。
Re:GUI toolkit 多すぎ!! (スコア:1)
さすがに今更 OPENLOOK モノの面倒を見るのはちょっと... (;_;)
Re:GUI toolkit 多すぎ!! (スコア:3, 興味深い)
C++ 自体は嫌いではないので、昨今の gcc 事情を見るに、後はコンパイル速度だけがネックなのではないかと思っているのですが。
Re:GUI toolkit 多すぎ!! (スコア:1)
Qt が普及するかという点については、Windows 用 Qt の GPL/QPL 版が出てこないと難しいと思います。 GTK+ が LGPL なのに対して Qt は GPL/QPL だから...という話もありますが、ソースを隠したければ商用 Qt を使えば済むことですから、そちらはあまり問題にならないでしょう。 Class library の好き嫌いで言えば GTK+ よりも Qt の方が好きなので、健闘して欲しくはあるのですが。
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)
Re:GUI toolkit 多すぎ!! (スコア:1, 興味深い)
結構多いのじゃよ。ライセンスも厳密にはアレゲであるし。。。
# Qt 利用の製品開発者なので AC
Re:GUI toolkit 多すぎ!! (スコア:1)
私は ATOKX の開発者でも Wnn の開発者でもありませんので完全な憶測ですが、Qt が C++ からしか使えなかったことの方がネックだったのではないでしょうか?
Re:GUI toolkit 多すぎ!! (スコア:1, 参考になる)
Re:GUI toolkit 多すぎ!! (スコア:1)
# あれ~、昔もっと高かったはずなのにな~
# とは思ったのですが...反省反省。(^^;
Re:GUI toolkit 多すぎ!! (スコア:1)
また、kdebindingsにQtCというものがあります。
Re:Sylpheedが動いてくれれば、、。 (スコア:3, 興味深い)
Re:Sylpheedが動いてくれれば、、。 (スコア:2)
UNICODEでしか扱えない文字を使わなければ
UTF-8にならないと思いますが…。
# Mail.app 常用なのでID
[udon]