アカウント名:
パスワード:
でも、KHTML のソースに、直接 Cocoa API を呼ぶようなルーチンを書いたのなら、あまりよくないでしょうね。
「あまりよくない」もなにも、KDEのツールであるKHTMLにMacOSXのAPI呼び出すルーチンを書くなんてありえないでしょう？ Mac上でしか動かない拡張をKHTML本体に導入するなんて論外。 そもそも729617 [srad.jp]の書き込みの主題として「何をしたい」のでしょうか？ KonquerorにSafariと全く同じレンダリング能力を持たせたい？ それもMacというプラットフォーム限定で
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
最初のバージョンは常に打ち捨てられる。
またやった…… (スコア:1, 参考になる)
タレコミ子です……
私の誤読を編者のかたが補足してくださいました。
KHTML云々の詳細はsaito氏のブログ [hatena.ne.jp]に概略があります。
また、Geckoに関しては謎氏の試行 [infoseek.co.jp]も参照のこと。
Re:またやった…… (スコア:1)
・WebKitではCSS2.1をフルサポートするためにCocoaのAPIを多用している
（陰影や透明度、あるいは音声関連？）
・本家KHTMLに流用しようにもQtにはそのようなAPIが無い
という妄想に至ったんですが実際のところはどうなんでしょ？
Re:またやった…… (スコア:1)
＞ （陰影や透明度、あるいは音声関連？）
これは賛否両論出るでしょうね。
陰影や透明度は、もともと OS の描画エンジンがする仕事だと思うので、WebKit が Cocoa API を利用してもよいのではと思います。でも、KHTML のソースに、直接 Cocoa API を呼ぶようなルーチンを書いたのなら、あまりよくないでしょうね。
Cocoa と Qt の API の違いを吸収するような API を作って、KHTML からはそれを呼ぶとか。いっそのこと、Mac OS X に
Re:またやった…… (スコア:2, 興味深い)
「あまりよくない」もなにも、KDEのツールであるKHTMLにMacOSXのAPI呼び出すルーチンを書くなんてありえないでしょう？
Mac上でしか動かない拡張をKHTML本体に導入するなんて論外。
そもそも729617 [srad.jp]の書き込みの主題として「何をしたい」のでしょうか？
KonquerorにSafariと全く同じレンダリング能力を持たせたい？
それもMacというプラットフォーム限定で
Re:またやった…… (スコア:1)
＞Mac上でしか動かない拡張をKHTML本体に導入するなんて論外。
#ifdef とかで、アーキテクチャ別にルーチンを書きわけるようなイメージをしていました。透明を実現するとき、Mac OS X なら Cocoa API を呼び出して、そうでないなら Qt か何かを呼ぶとか、そういうイメージ
Re:またやった…… (スコア:1)
でしたね。失礼しました。
しかしですね、KDEのデベロッパーが言ってるのは
「AppleがSafariでやったことはMacOSXの機能に依存するものであり、KHTMLには（たとえAppleがソースを公開しても）簡単には移植出来ないし、するつもりもないよ」
ってことですよね。
これは「Appleの拡張を使わない[と|ので]CSS 2.1を完全に実現出来ない」という意味ではないですね。
現行のQtを使い、KDE側が透明などの機能を実装するのは不可能なのでしょうか？
パネルを透明化するツールがあったりするので、不可能ではないように思うのですが…。
もしプラットフォームごとに違う手段で実装するしか方法がないなら、KonquerorがWebKitを使えるようにする方が現実的じゃないでしょうか？
＃しかし、そこまでしないといけないとなると、マルチプラットフォームの利点ってなんだろう？
Re:またやった…… (スコア:0)
>でしたね。失礼しました。
いつのQtだ、それは。QtはGPLなんだけど・・・。(forkによる問題は置いておくとして)
(理解してないだけならいいが、それが根拠に論を作られても議論できないぞ)
>現行のQtを使い、KDE側が透明などの機能を実装するのは不可能なのでしょうか？
>パネルを透明化するツールがあったりするので、不可能ではないように思うのですが…。
Qtは3ではまともなtransparentの機能を持っていません。パネルの透明化などはKDEがXrenderを直にたたいてるのではなかったか