アカウント名:
パスワード:
巨大なブラックボックスの上に乗っかってもあまり嬉しくないような気がするけれども。
じゃあ cygwin も否定されます?
なにが嬉しいのか見えにくくて。
重いかもしれない (というか、ただでさえ遅い cygwin 上で動作するのだから間違いなく遅いと思う) ですが、兎に角「動く」「使える」事に意味があるのだと思います。 諸々の事情で Windows 以外の OS を使えない方もいらっしゃるでしょうし。
INTERIX みたいに NT kernel 上のサブシステムとして乗っかってしまえば速度はもっと稼げるとは思いますが、確かサブシステムを作るには Microsoft の許可が必要だった様な気が (詳しい方、フォロー願います)。
コンパイラやリンカの問題だと思います。 Qt固有の問題ではないですね。
取りあえずCygwinはファイル等の扱いがバリ遅いという性質があるので、この部分を直さな いとKDEなんて本当に使い物にならないような・・・
じゃあ cygwin も否定されます? <!-- snip --> 存在意義は cygwin と同じだと思いますが。
同じ動作をするツールがあることが大事 (=ASCII-Tools) なのではなく、同じツールを使えることが大事 (=cgywin) なのかな。
# が、手元の箱では cygwin の X が何故か動かない。 # これでは KDE on cygwin も存在しないのと同じぢゃ (;_;)
そりゃ、「そこに山があるから登る」でしょ?
NetBSDの方々に「なんでブラックボックスなCEマシンにまで移植するんですか?PCがあるからいいじゃないですか」と聞いてみるのに等しいような。山は登ってみてこそ、その価値が分かるという物です。
さあ、みんなで登るのだ!個人的にはKDE/Cygwinはいらないけど:-)
GPLソフトウェアに非GPLなライブラリをリンクしての配布は禁止です。
毎度のことながらライセンスが絡むと話がややこしくなる。
#単に私の頭が法律家向きじゃないだけかもしれないが(笑)
VC++でmakeされたGNUツールってあちこちに転がってるような気がするんですが、全部ダメってこと?
現状では、KDEをWindowsで動かすために、 Windows(ネイティブ)版のQtは使えませんということになりますよね。
そこで、GPLで配布されているX11版のQtをWindowsに移植してしまったらどうなるのっていう、なんとも微妙なアイディアも浮かんできたりします。Qtの方がすっきりしている分、GDK/Win32よりはだいぶ楽なんじゃないかと邪推してます。
補足:
GPLで配布されているX11版のQtをWindowsに移植
もちろんXFreeではなくてWin32APIベースに、ということです。
このntxlibってどんなものかご存知の方はいませんか?想像する に、Windowsネイティブな表示ができてXlib互換なインターフェースを持つライブラリ??
ntxlib.zip [microsoft.com]: これですね。microsoftに置いてあ
先に書いたntxlib.zipのはずいぶん古くて1992年でした。 以下に比較的新しいのを見つけましたので書いておきます:
先に書いたntxlib.zipのはずいぶん古くて1992年でした。 以下に比較的新しいのを見つけ ましたので書いておきます:
時間帯が時間帯とは言え寝ぼけてて済みません。上記のは普通のXライブラリ、以下のが比較的新しいと思われるntxlibです:
GPL [key.ne.jp]第4項に
特別な例外として、実行可能なファイルが動作するオペレーティング・システムの主要な構成要素(コンパイラ、カーネルなど)と共に(ソース・コード又はバイナリのどちらかで)頒布されているものについては、その構成要素自体が実行形式に付随していない場合に限り、頒布されるソースコードに含める必要はありません。
と書いてあるので大丈夫なんじゃないでしょうか。
ライセンスって本当にややこしいですよね。特にGPLはとてもややこしい。
要約すると「GPLなアプリから非UNIXなQTを使いたい場合には、そのアプリのライセンスに非商用QTに関する例外条項を設けてくれ」ってことみたいですね。っつーことで、WindowsネイティブKDEってのは、KDE側がライセンス的に譲歩しない限りはありえないですし、逆にKDE側が本気で「WindowsネイティブなKDEを作る」と決心すれば無理な話でもないでしょう。
#依然として、そこまでしてWindows版を作る意味があるか、という問題は残りますけどね。
ちなみに、俺の前の投稿は、単にそっちの方がチャレンジとして面白いんじゃないか、って思って書いただけっす。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲは一日にしてならず -- アレゲ研究家
順序が逆のような (スコア:2, おもしろおかしい)
なにが嬉しいのか見えにくくて。
Re:順序が逆のような (スコア:2)
じゃあ cygwin も否定されます?
存在意義は cygwin と同じだと思いますが。重いかもしれない (というか、ただでさえ遅い cygwin 上で動作するのだから間違いなく遅いと思う) ですが、兎に角「動く」「使える」事に意味があるのだと思います。 諸々の事情で Windows 以外の OS を使えない方もいらっしゃるでしょうし。
INTERIX みたいに NT kernel 上のサブシステムとして乗っかってしまえば速度はもっと稼げるとは思いますが、確かサブシステムを作るには Microsoft の許可が必要だった様な気が (詳しい方、フォロー願います)。
Re:順序が逆のような (スコア:1)
面白い試みとか言う前にやはり「使える」ように整備する必要もあるかなって思います。
Re:順序が逆のような (スコア:1)
色々あるんでしたよね。
C++のメソッドの動的リンク(を、アプリ起動するたびに
「全クラスに対して」毎度行なうので遅い)とかの問題ってのは
もうカタがついたんでしょうか?#あれはコンパイラの問題なのかな…
Re:順序が逆のような (スコア:1)
>「全クラスに対して」毎度行なうので遅い)とかの問題ってのは
>もうカタがついたんでしょうか?#あれはコンパイラの問題なのかな…
コンパイラやリンカの問題だと思います。
Qt固有の問題ではないですね。
詳しくは今月号の『Linux Japan』と、
objprelinkのページ [att.com]及びそのリンク先参照
Re:順序が逆のような (スコア:2)
その通りです。大規模で複数のC++のクラスベースのライブラリを
リンクしているアプリではQt, KDEに限らず起こりうる問題です。
binutilsやglibcの開発版では修正のための作業 [kde.org]を行っているはずです。
-- Che Che - Bye Bye
Re:順序が逆のような (スコア:0)
Re:順序が逆のような (スコア:1)
ふむふむ、なるほど。
わたしはcgywinは往年のASCII-Toolsのような感覚で捉えていましたが、そこに間違いがあった訳ですね。同じ動作をするツールがあることが大事 (=ASCII-Tools) なのではなく、同じツールを使えることが大事 (=cgywin) なのかな。その延長上には、当然KDE on Windowsがやってくるわけですね。
思想として実装することに意味があって、重くて使い物にならないというようなことは、実装した後の問題なのか。
Re:順序が逆のような (スコア:2)
# が、手元の箱では cygwin の X が何故か動かない。
# これでは KDE on cygwin も存在しないのと同じぢゃ (;_;)
Re:順序が逆のような (スコア:2, おもしろおかしい)
そりゃ、「そこに山があるから登る」でしょ?
NetBSDの方々に「なんでブラックボックスなCEマシンにまで移植するんですか?PCがあるからいいじゃないですか」と聞いてみるのに等しいような。山は登ってみてこそ、その価値が分かるという物です。
さあ、みんなで登るのだ!個人的にはKDE/Cygwinはいらないけど:-)
Re:順序が逆のような (スコア:1, 興味深い)
個人的には用途云々とかに関する思考よりも、おもしろい試みであるという思いの方が強かったり。
KDE使いとしては、意味もなく期待したい所。
Re:順序が逆のような (スコア:1)
Re:順序が逆のような (スコア:1, 参考になる)
どうもライセンスが絡むと… (スコア:1)
毎度のことながらライセンスが絡むと話がややこしくなる。
#単に私の頭が法律家向きじゃないだけかもしれないが(笑)
VC++でmakeされたGNUツールってあちこちに転がってるような気がするんですが、全部ダメってこと?
Re:どうもライセンスが絡むと… (スコア:1)
それで、KDEはQtとリンクしなければならないですから、
現状では、KDEをWindowsで動かすために、
Windows(ネイティブ)版のQtは使えませんということになりますよね。
Re:どうもライセンスが絡むと… (スコア:1, 興味深い)
そこで、GPLで配布されているX11版のQtをWindowsに移植してしまったらどうなるのっていう、なんとも微妙なアイディアも浮かんできたりします。Qtの方がすっきりしている分、GDK/Win32よりはだいぶ楽なんじゃないかと邪推してます。
Re:どうもライセンスが絡むと… (スコア:0)
補足:
もちろんXFreeではなくてWin32APIベースに、ということです。
Re:どうもライセンスが絡むと… (スコア:1)
>Windowsに移植してしまったらどうなるのっていう、
>なんとも微妙なアイディアも浮かんできたりします。
技術的には、たぶん一番面白いアプローチでしょうね。
「X11上でないと使っちゃダメ」とかできなさそうだから、
ライセンス的には大丈夫なのかな?
#よく調べていない
やり方によっては、
KDEプロジェクトとtrolltechとの関係が心配になりますが。
#だからそういう活動が存在していないのではないかと、想像
Re:どうもライセンスが絡むと… (スコア:1)
>> >Windowsに移植してしまったらどうなるのっていう、
>> >なんとも微妙なアイディアも浮かんできたりします。
>> 技術的には、たぶん一番面白いアプローチでしょうね。
>> 「X11上でないと使っちゃダメ」とかできなさそうだから、
>> ライセンス的には大丈夫なのかな?
UNIX向けQTを使って開発したGPLなソフトには、QTもGPLが適用されるはずなので問題無いはずですね。で、元記事からリンクされている KDE on Cygwin [sourceforge.net]のページに書いてありますが、
Donald Becker has told, that he is working on an x emulation lib for providing a native running kde on Windows.
だそうで、まぁ誰しも考えることは同じですねぇ。これが完成したときには、KDEとTrollTech社との関係がこじれる可能性はあると思いますけど、逆にそうなった時点でTrollTech社が諦めてWindows版もGPLにするという可能性もありますしね。;-)
ところで、上記引用文に続いて
Currently he is verifying, if the ntxlib is usable for this.
って書いてあるんだけど、このntxlibってどんなものかご存知の方はいませんか?想像するに、Windowsネイティブな表示ができてXlib互換なインターフェースを持つライブラリ??
Re:どうもライセンスが絡むと… (スコア:0)
ntxlib.zip [microsoft.com]: これですね。microsoftに置いてあ
Re:どうもライセンスが絡むと… (スコア:0)
先に書いたntxlib.zipのはずいぶん古くて1992年でした。 以下に比較的新しいのを見つけましたので書いておきます:
Pre-compiled X11R6.4 Libraries/Clients For CYGWIN B20 [nasa.gov]Pre-compiled X11R6.3 Libraries/Clients For GNU Win32 B19 [nasa.gov]
Re:どうもライセンスが絡むと… (スコア:0)
時間帯が時間帯とは言え寝ぼけてて済みません。上記のは普通のXライブラリ、以下のが比較的新しいと思われるntxlibです:
ntxlib02.tgz [nasa.gov]VC++でmakeされたGNUツール (スコア:1)
GPL [key.ne.jp]第4項に
と書いてあるので大丈夫なんじゃないでしょうか。
ライセンスって本当にややこしいですよね。特にGPLはとてもややこしい。
Re:VC++でmakeされたGNUツール (スコア:2, 参考になる)
要約すると「GPLなアプリから非UNIXなQTを使いたい場合には、そのアプリのライセンスに非商用QTに関する例外条項を設けてくれ」ってことみたいですね。っつーことで、WindowsネイティブKDEってのは、KDE側がライセンス的に譲歩しない限りはありえないですし、逆にKDE側が本気で「WindowsネイティブなKDEを作る」と決心すれば無理な話でもないでしょう。
#依然として、そこまでしてWindows版を作る意味があるか、という問題は残りますけどね。
ちなみに、俺の前の投稿は、単にそっちの方がチャレンジとして面白いんじゃないか、って思って書いただけっす。
Re:順序が逆のような (スコア:1)
まずは「WindowsネイティブなQtをGPLにしてくれー」といった
活動が必要だし、そっちの方が面白いかも。
そして、KDEのX11に依存したコードになっている部分を
書き換える(書き加える)と。
でも、その前に、FreeBSD等でもLinuxと同じくらいに
簡単かつ快適にKDEを使えるようにしないとね。
Re:順序が逆のような (スコア:0)
> 簡単かつ快適にKDEを使えるようにしないとね。
へ? FreeBSD の packages/ports で簡単快適に使ってますが...
Re:順序が逆のような (スコア:1)
ソースコードからコンパイルして
環境の設定をするのに苦労するって話ね。
あと、それに付属するのかもしれないけど、
たまにLinuxでは使えるけど
ほかの環境だと使えなかったりするアプリもある。
ここが解決されないと、
最新の環境が使えるようになるまで時間がかかるし、
KDEプロジェクト自体から提供される
ソースパッケージに入っていないアプリについては、
そう簡単に使えないものも出てくる。
FreeBSDユーザーではないので、
もう解決されているかもしれませんが。