#ifdef とかで、アーキテクチャ別にルーチンを書きわけるようなイメージをしていました。透明を実現するとき、Mac OS X なら Cocoa API を呼び出して、そうでないなら Qt か何かを呼ぶとか、そういうイメージです。
CSS 2.1 を完全に実現するために、アーキテクチャ別に振り分けて実装するしか方法がないなら、仕方ないのではと思います。
Qt の根本的解決を図るのがすっきりしているのは、もちろんだと思いますが、Qt は Apple も KDE 開発者もいじれないんではなかったでしたっけ?
またやった…… (スコア:1, 参考になる)
タレコミ子です……
私の誤読を編者のかたが補足してくださいました。
KHTML云々の詳細はsaito氏のブログ [hatena.ne.jp]に概略があります。
また、Geckoに関しては謎氏の試行 [infoseek.co.jp]も参照のこと。
Re:またやった…… (スコア:1)
この文がどこにかかるのかがよくわかりません。
たぶん、
先日登場した Opera 8 および Mozilla の最新開発版においても
Acid2 Test は完全にはクリアされていない。
↓
これらでAcid 2 Testをクリアさせるためには、まだパッチが必要。
といいたいのだと思うけど、
たれ込みは早とちりで、実は最新のSafariにパッチを当てることで
Acid 2 Testをクリアできただけ。
のようにも読めます。
Re:またやった…… (スコア:3, 参考になる)
Tiger に付属した Safari そのままではまだテストをクリアできないということです。 なお、Gecko と Operaについては kota [hatena.ne.jp] 氏のブログを参照。
Re:またやった…… (スコア:2)
すいません。言葉が足りませんでした。
こっちの方でしたので、補足に加筆しておきました。
ちなみに、Darwin 8.0 (Mac OS X 10.4相当)のソース [apple.com]も公開されましたので、WebCore-413 [apple.com]にHyatt氏のパッチ [mozillazine.org]を当ててビルドすれば、Acid2 TestをクリアできるSafariを使えるようになると思います。
Re:またやった…… (スコア:0)
なんだかなぁ。
Re:またやった…… (スコア:1)
# 「パッチを当てた」が欠落しちゃあなぁ...
Re:またやった…… (スコア:1)
公開はされている (スコア:0)
- Safari が Acid2 Test をクリアした最初の主要 Web ブラウザになった
- ただし公開されているソースとパッチから自分でビルドする必要がある
正式公開されていない物を認めないことにすると、MozillaなどはSVGが実装されていないことになる。Re:公開はされている (スコア:0)
ここだけ読むと、Tiger付属のバージョンのSafariでAcid2 Testをクリア出来るように読めるのが、タレコミ文の最大の問題じゃないかな。
わざわざTiger付属と補足するから分かりづらくなってる気がする。
Re:公開はされている (スコア:1)
なるほど。ということで修正しておきました。
Re:またやった…… (スコア:1)
1を聞いて0を知れ!
Re:またやった…… (スコア:1)
・WebKitではCSS2.1をフルサポートするためにCocoaのAPIを多用している
（陰影や透明度、あるいは音声関連？）
・本家KHTMLに流用しようにもQtにはそのようなAPIが無い
という妄想に至ったんですが実際のところはどうなんでしょ？
Re:またやった…… (スコア:2, 興味深い)
＃Safariは CSS より JavaScript の実装を何とかしてほしい。var 必須はちょっと、、
Re:またやった…… (スコア:0)
Safari 1.3や2.0でJavaScriptが改善されたということで使ってみたら、実行速度が改善されただけで文法解釈のほうは相変わらずですからね…
というわけで相変わらず多くのサイトでJavaScript周りのトラブルが起きていて、正直Safariは使い物になりません。この
Re:またやった…… (スコア:0)
GeckoがAcid2 Testをパスしたら検討するかも知れませんねぇ。
Re:またやった…… (スコア:1)
＞ （陰影や透明度、あるいは音声関連？）
これは賛否両論出るでしょうね。
陰影や透明度は、もともと OS の描画エンジンがする仕事だと思うので、WebKit が Cocoa API を利用してもよいのではと思います。でも、KHTML のソースに、直接 Cocoa API を呼ぶようなルーチンを書いたのなら、あまりよくないでしょうね。
Cocoa と Qt の API の違いを吸収するような API を作って、KHTML からはそれを呼ぶとか。いっそのこと、Mac OS X に Qt/Mac を標準搭載しちゃうとか。後者の方が API 的にはすっきりするけど、パフォーマンスや見た目はどうなんだろう?
Mac 版 FireFox の描画はあんまりきれいじゃないから好きになれないので、それと似たことが KHTML + Qt/Mac で発生するなら、その手法はあきらめる (KHTML が Cocoa を直接呼ぶ) のも仕方ないかな。
Re:またやった…… (スコア:2, 興味深い)
Mac上でしか動かない拡張をKHTML本体に導入するなんて論外。
そもそも729617 [srad.jp]の書き込みの主題として「何をしたい」のでしょうか？
KonquerorにSafariと全く同じレンダリング能力を持たせたい？
それもMacというプラットフォーム限定で？
Macから見れば、それにメリットがあるとは思えない（すでにMacOSXで出来ることをQt/Macで可能にするだけ）し、KDEから見れば、KDE本体にはなんらフィードバックはない。
他プラットフォームで動かない独自拡張をKDEあるいはQtに導入するよりは、Qtの根本的改良に期待する方がずっとすっきりしてると思いいますが。
Re:またやった…… (スコア:1)
＞Mac上でしか動かない拡張をKHTML本体に導入するなんて論外。
#ifdef とかで、アーキテクチャ別にルーチンを書きわけるようなイメージをしていました。透明を実現するとき、Mac OS X なら Cocoa API を呼び出して、そうでないなら Qt か何かを呼ぶとか、そういうイメージです。
CSS 2.1 を完全に実現するために、アーキテクチャ別に振り分けて実装するしか方法がないなら、仕方ないのではと思います。
Qt の根本的解決を図るのがすっきりしているのは、もちろんだと思いますが、Qt は Apple も KDE 開発者もいじれないんではなかったでしたっけ?
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を直にたたいてるのではなかったか
Re:またやった…… (スコア:0)
Re:またやった…… (スコア:0)
近代的なビルの中にほったて小屋を建てる様なもの
Re:またやった…… (スコア:0)
WebCoreはWebKitとのやりとりを除いてはC++で書かれていて、CocoaのAPIを呼び出すようなことはしていません。ですが、XML関連の問題を解決するためにCoreFoundationを呼び出している部分はあります。マルチメディア関連はWebCoreの範囲外です。
Hyatt氏のブログ [mozillazine.org]によると、パッチにはKWQ(QtのA
Re:またやった…… (スコア:0)
Unicode Utilitiesも使ってる。テキストレイアウトにはATSUIも使う。
これらのCarbon APIはUnicode処理の中心だからOSXで動かす限り
これらを排除することはできない。