Site Meter

2008年3月29日

未來 Konqueror 將導入 WebKit 做為預設渲染引擎

  其實去年底就有聽到這樣的風聲了, KDE 工作團隊打算將自家開發的渲染引擎 KHTML 併入 KHTML 的分支— WebKit (WebKit 是蘋果專為 Safari 所設計的渲染引擎)。在 Konqueror 第四版出來後, KDE 的工作團隊也開始著手將 WebKit 導入 Konqueror 4 ,截至目前為止已經初具雛型了,不過由於原本的 KHTML 工作團隊分成兩派人馬,一是傾向於轉向 WebKit 開發,另外則是死守 KHTML 的開發者,所以基本上 KHTML 在短期內應該還不至於消失

  就我個人的看法而言,依照 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 來說是意義非凡

2 則留言:

  1. 感謝熱心描述。

    不過,現在 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

    回覆刪除
  2. KDE team 的確做了許多很有遠見的設計,但就一些消息指出, KDE Team 的確是打算使用 WebKit 來做為預設的渲染引擎,雖然還有工程師堅持繼續開發 KHTML ,但誰都不敢保證後續會如何發展,這是我比較擔心的部分。

    回覆刪除

請注意,在較舊的文章留言並不會馬上出現在回應區!