
就我個人的看法而言,依照 Konqueror 和 Safari 的軟體能見度來說, Safari 當然是遠大於 Konqueror ,因此 WebKit 受網頁設計師支援以及重視的程度也當然就會比 KHTML 大很多(更何況使用 WebKit 的瀏覽器並不止 Safari),所以就通行度而言,引入 WebKit 對於 Konqueror 來說的確是件好事。
但是 KHTML 是 KDE 自己專為 Konqueror 而量身打造的渲染引擎,不但是Konqueror 的渲染引擎,更是整個 KDE 的渲染引擎, KHTML 對於 Konqueror 來說,意義非凡,若是沒了 KHTML ,就我個人的觀點認為,那 Konqueror 恐怕就只剩外殼了(就像 KKBOX 和 Galeon 那樣,是沒有自己核心的瀏覽器)。所以我認為 KHTML 不應被 KDE 團隊所忽視。
但就情勢來說, KHTML 現在應該算弱勢,未來所剩的 KHTML 開發者也有可能因為感到大勢已去而紛紛轉向 WebKit 開發,直至 KHTML 消失為止。
雖然我贊同 Konqueror 導入 WebKit ,但我還是傾向於使用 KHTML 做為預設的排版引擎,讓我們可以在必要時切換到 WebKit 就好,我不贊成將 WebKit 做為預設渲染引擎,尤其不贊成 KHTML 開發者轉而開發 WebKit ,原因很簡單,因為我認為 KHTML 對於 Konqueror 甚至是整個 KDE 來說是意義非凡。
感謝熱心描述。
回覆刪除不過,現在 KDE KHTML team 的作法是不定期 merge WebKit 的修改,同時也提交本身的修改。而 Qt WebKit (Qt 4.4 內建) 則是扮演橋樑的角色,一旦 Qt WebKit 成熟後,KHTML 就能直接採用 WebKit 成果並完全整合到 KDE 技術,如 KIO 一類的 framework。
即便如此,KHTML/Konqueror 當然還會存在,不只是「殼」,仍是 KDE Framework 最重要的技術呈現者。
有意思的是,許多 KDE 2 的決策,經歷近十年,仍是相當有遠見的設計。
Ref: http://jserv.sayya.org/kde/zh_TW_kpart-techno.html
KDE team 的確做了許多很有遠見的設計,但就一些消息指出, KDE Team 的確是打算使用 WebKit 來做為預設的渲染引擎,雖然還有工程師堅持繼續開發 KHTML ,但誰都不敢保證後續會如何發展,這是我比較擔心的部分。
回覆刪除