- 2007.4.1-Subsystem Freeze(子系統凍結)
- 2007.5.1-Alpha Release + kdelibs soft API Freeze(發佈 Alpha 測試版,凍結 kdelibs soft API)
- 2007.6.1-Feature Freeze(特性凍結)
- 2007.6.25-2007.9.24-Beta Cycle, Full kdelibs API Freeze(發佈 Beta 測試版,凍結所有 kdelibs API)
- 2007.9.25-2007.10.22-Release Candidate Cycle(發佈正式候選版版)
- 2007.10.23-KDE 4.0 Released(發佈正式版)
2007年3月30日
KDE 4.0 發佈時程
2007年3月10日
通向 KDE 4 之路(九):Dolphin 與 Konqueror
首先大家對 KDE 中的檔案管理員作一個回顧:出現在 KDE 1.x 中的是 KFM(KDE 檔案管理員),它是一個初步擁有一定網路瀏覽功能的檔案管理員。下面是一張 KFM 的截圖(從 kde.org 的庫裡找出來的),從圖中您可以對它的介面有一個瞭解。
雖然從 KDE 1.x 開始,KDE 已發展了很多年了,但仍然可以很輕易地發現 KFM 的某些部分影響了 Konqueror 的設計,那些設計就被加入了當時的 KDE 2.0 中。KParts 技術為我們的檔案管理程式帶來了新的革命,同時也造就了 Konqueror 這個集網路瀏覽器、檔案管理員等功能為一體的強大程式。下面是張 KDE 3.5.6 中 Konqueror 的截圖,您可以看到雖然界面改進了很多,但依然可以看到當年 KFM 的影子。Konqueror 實為 KDE 2.x 和 3.x 系列中 KDE 技術的代表作,它展現了 KDE 技術中最優秀的部分。Konqueror 顯示了 KDE 的 IOslaves 技術的強大,這個技術使得您通過 FTP、fish(SSH)、HTTP 以及其它協定進行檔案操作時實現網路的透明化(網路操作時與在本機操作一樣方便)。Konqueror 是如此的先進,只要您在網址列填上 FTP 網址,您就可以像在本機上一樣操作它(據我所知,只有 Konqueror 能做到這點)。它的 KParts 功能可以令它嵌入各種所需的檢視器,如可以直接在它的界面中嵌入如 KPDF、KWord、圖片檢視器,當然還有我們最重要的 KHTML 網頁排版引擎。有了 KParts,Konqueror 的圖示檢視功能也可作為一個插件來實現。
Konqueror 真是個強大的工具,它可以完成您或您的系統想做的任何事,並且可以通過模塊和插件無限制地對它進行自訂和擴充。當 Konqueror 用作網路瀏覽器的時候,它仍然可以以一個檔案管理員的方式工作。看看 Konqueror 的工具列上的按鈕吧,您可以輕易地注意到這種獨特的運作方式。例如工具列的那個「向上」按鈕在您瀏覽 Google Map 的時候仍然可用。但它與網頁內容一點關係也沒有,另一個例子是當您在排列 /home/ 裡的圖示時,它的網路書籤依然可用。
Dolphin 的介紹:Dolphin 是 KDE 4 中的新檔案管理員,它完全著重於檔案管理功能而不是像 Konqueror 那樣萬能的程式。它試圖最佳化與檔案管理的相關工作,並為 KDE 用戶提供一個易於使用的靈活檔案管理員。這並不意味著它功能匱乏或無法自訂,這只是表示 Dolphin 是為單一目的而建構的。
Dolphin 也不是完全重寫的新項目,也沒有與 Konqueror 競爭的打算,這兩個程式都將得到喝彩。Dolphin 使用 KDE 平台上已存在的 IO slave 來完成遠端或本機檔案管理,也就是說它可以勝任所有「遠端」管理之類的任務,而此功能正是得益於 Konqueror。Dolphin 將不會顯示網頁或像 Konqueror 一樣嵌入顯示 PDF 文件。
Konqueror 也將從 Dolphin 中受益。雖然 Konqueror 的用戶界面會有所調整,它也不再是 KDE 4 的預設檔案管理員了,但是它不會在 KDE 4 中消失。Konqueror 的檔案管理功能仍然會得到保留,其功能與過去一致沒有改變。在 Dolphin 的開發而帶來的對 KDE 的圖示檢視部分的改進也將影響 Konqueror ,因為他們共享同樣的程式庫。前面提到的 Konqueror 使用 KParts 實現圖示功能,對於底層的 KParts 的改進將使 Konqueror 的用戶受益。
現在讓我們看看 KDE SVN 庫中的 Dolphin 和 Konqueror 的截圖吧。請注意這些截圖代表的是開發者目前所設計的樣子,而這並不意味著它最後的功能和外觀就是如此,也不表示推薦大家編譯 SVN 中的這兩個軟體作為日常使用。
您可以將 Konqueror 設定為預設使用標籤瀏覽,也可以設定其它相關界面。它目前常作為一個網路瀏覽器來使用,只是偶爾被用於檔案管理。 Konqueror 最初就是由檔案管理員衍生而來,現在越來越多的KDE用戶將它作為網路瀏覽器。作為一個網路瀏覽器,Konqueror 工作的很好,它對 CSS 3 的相容性非常出色,包括對高度期望的「不透明標籤」的支援也很好。
在 KDE 3.x 中 Konqueror 的網路瀏覽器功能不斷改進的同時,其標準的檔案管理功能也將得到維護。而它檔案管理部分的程式碼與 Dolphin 共用,從而也從 Dolphin 的開發中獲益。
Dolphin 與 Konqueror 完全不同,它是一個「真正」的檔案管理員,它的界面中的大量元素是專門為檔案管理開發的,它也不會由於要作為一個網路瀏覽器而被迫調整。可以用一個截圖來證明:
請注意 Dolphin 的「breadcrumb」式的目錄選擇器,這個東西對於檔案管理時非常有用,但如果您需要使用瀏覽器的 URL 網址時它就沒什麼用了,因此它就是那種只用於層次檔案處理的視窗小部件。對於用過 OS X 的 Finder 或 GNOME 的 Nautilus 的朋友來說,breadcrumb 部件應該不陌生吧。對上面這張截圖的另一個註明是:點擊並按住一個 breadcrumb 目錄條時,它會出現一個跳出式選單,這個選單顯示的是與其目錄同一層的資料夾,這就提供了更高效率的文件導航了。
不過也不一定要用 breadcrumb ,如果您更喜歡 Konqueror 式的網址列的話,在設定中做個更改就行了。Dolphin 的可自訂性也很高,看下面。
這張截圖證明了 KDE 在設定方面花了不少心思,它盡可能提供了各種需要的選項但設定內容的排列上卻清清楚楚。請注意 KDE 4 設定對話框的改進。當然對某些螢幕來說,它的對話框顯得太大了,有些地方尚需修改。等 Oxygen 圖像組件齊全之後,這個對話框也會更容易看了。
Dolphin 的功能也不完全是新的,它只是換了個新的方式而已。它可以看作是 Konqueror 功能和 Nautilus 架構的混合體。Dolphin 建構於壯健的 KDE 基礎之上,它重新利用了如 KIO slaves 等現有技術,並有所創新。在 Konqueror 中常用的右鍵選單仍然會最大限度的保留(只是 Donphin 不會像 Konqueror 那樣嵌入檢視器,它會在外部啟動程式)。Konqueror 現在的開發則專注於其網路瀏覽器,而在 KDE 2.0 時代就具備的檔案管理功能仍將支援。
當 KDE 4 發佈的時候,Dolphin 將設為本地 file:/ 協定的預設程式,在程式選單中它也將被設為是預設的檔案管理員。Konqueror 則是預設的網路瀏覽器,為了KDE用戶長期以來的習慣,它的檔案管理員功能仍然可用。就像 KDE 3.x 中用戶也可以將第三方的程式如 Krusader 作為預設的檔案管理員那樣,用戶也可以設定他們喜歡的程式作為預設檔案管理員。請繼續關注 Dolphin 和 KDE 的消息,下週見。
原文:The Road to KDE 4: Dolphin and Konqueror by Troy Unrau
譯文:通向 KDE 4 之路(九):Dolphin 與 Konqueror by yuanjiayj
2007年3月1日
[轉載]通向 KDE 4 之路(八):CMake,新的 KDE 構建系統
當一個項目的規模發展到像 KDE 這樣龐大的時候,對既定設計的變更比起十年前要困難多了。起初,KDE 依靠 autotools 工具集來構建大部分的項目,但從去年開始,KDE 4 將改用一個全新的構建系統,CMake。我們認為它將很快成為世界上現存的各種構建系統中有力的競爭者之一。詳情見下。
本文會著重介紹 CMake,CMake 不屬於 KDE 項目,它是另一個獨立開源軟件小組 Kitware 的產品,以 BSD 授權協議發佈。雖然我恐怕無法用截圖這種形式來展現這種構建系統的特徵,但是我將儘可能通過文字描述 CMake 之所以會受到 KDE 開發組歡迎的原因。
不過在正式開始討論 CMake 之前,我打算先回顧一下 KDE 和 autotools 的關係史。KDE 創自 Qt,Qt 中有一個很棒的特性被稱為元對象編譯器(moc),而 autotools 若要支持 moc 作為大多數 KDE 頭文件的預處理器必須在功能上進行一些拓展。這種狀況只不過是個開始,為了在構建過程中自動生成並添加所需的文件類型,KDE 的開發者寫了許多自用的 DCOP 通訊協議完成這一工作,比如加入文檔編譯器、語言包自動處理器、從 XML 中生成配置文件樣本、Qt 用戶界面編譯器(就是那些 .ui 文件)等,我們希望構建系統能支持對這些操作的處理。更甚者,我們還企求 KDE 構建系統能支持預配置、編譯選項等一系列完整的工程流水線。久而久之,現在的 KDE 構建系統已經演變得像一隻由各種器官雜湊出來的怪獸,就算這樣,autotools 也還是不能完全滿足我們的需求。
在 KDE 3 時代,僅有極少數所謂「編譯專家」才能通徹地熟悉整個 KDE 構建系統,不瞭解內情的 KDE 開發者若想把一個組件從某文件夾移到另一個文件夾裡,別指望不花上幾個小時就讓這套代碼能再次成功編譯出來。甚至有時候,從頭開始一個獨立的 KDE 項目之前需要先部署 500K 左右的 autotools 配置,最終卻只是為了支持一個簡單的「hello world」類型程序。
事情很明顯了,KDE 4 必須做些什麼來擺脫這種窘境,在 Akademy 2005 會議中,我們決定要發掘其它可選用的構建系統。剛開始,SCons 一度成為新 KDE 構建系統的原型,但它還是太慢了,況且經過幾個月的工作,我們都沒能將 kdelibs 成功地從 autotools 完整遷移出去,其中一個很大的問題就是 SCons 在模塊化上有顯著的欠缺。
在這之後,有一名對 KDE 頗有貢獻的人士,Alexander Neundorf 決定嘗試將 KDE 遷移到 CMake 構建系統,這一流程居然相當順利,而且他本人還是 CMake 開發者的技術支持他是在 CMake 開發者的支持下完成這一工作的。接下來,我們只用了幾個星期就順利地把 KDE 中大部分東西用 CMake 構建成功,這樣 autotools 終於可以徹底地被驅逐了。
CMake 的開發者對 KDE 的遷移計劃給予了很多的援助,他們還參與到針對 KDE 構建系統的郵件列表裡一起幫忙,這種合作對彼此都有益處。就像 KDE 開發者會和 CMake 開發者展開交流,提出改進建議,這能促進 CMake 系統中某些落後設計加速進步──他們也很樂意提供反饋,這將使得 CMake 會對所有採用構建系統的項目都能及時給出有效的改進。
在我們的合作期間,CMake 為 KDE 的構建作出了大量的改良。使用 CMake 的項目可以花更少的時間完成構建系統的建設,開發者也一定希望用來折騰構建系統的精力越少越好。如一名 KDE 開發者所言:「CMake 不會再讓你構建項目時煩得只想往自己腦袋上來一槍。」
CMake 的核心是讀取一個容易理解的文本文件「CMakeLists.txt」,開發者可以往裡面添加自己的源碼目錄把 CMakeLists.txt 這個文件放在源代碼所在的目錄中。當您運行「cmake」命令時,它會尋找這個文件,根據裡面的內容生成標準的 Makefiles(UNIX 平台專用)或是利用命令行開關生成 XCode 項目文件(用於構建 OS X 系統上 XCode 開發工具所面向的 Mac 程序),甚至還能通過您的源代碼生成 MSVC 項目。此外,CMake 中還有個 KDE 相關的特色功能,它可以基於 「CMakeLists.txt」自動創建出對應的 KDevelop 項目文件,這裡的「CMakefiles.txt」和用來生成 Makefiles 的文件是一致的。
KDE 的代碼力圖確保相當的可移植性(有少數部分例外),然而這並不足以讓它能在 Windows 這樣的其它系統上構建,因為受到了 autotools 的局限。但是現在,由於構建系統能在別的操作系統上運行,KDE 自身也同樣可以了(當然,Qt 在其它平台上也已經是 GPL 了)。
在 KDE 3.x 中,推薦的 KDE 構建方式是像下面這樣:
% ./configure --prefix=/foo --enable-debug
% make
# make install
如您所知,上面那是非常標準的 autotools 構建模式,只是,控制構建進程的那些腳本可是太難弄懂了。
使用 CMake 的話,構建語法有所改變(在開閉配置選項上比舊形式更加直觀),但命令還是挺相似的,見下:
% cmake -DCMAKE_INSTALL_PREFIX=/foo \
-DCMAKE_BUILD_TYPE=debugfull .
% make
# make install
以上語法的變化幅度其實沒多大,但卻好懂多了。
CMake 搜索依賴對象的速度比「./configure」快了好幾倍,用 CMake 構建 kdelibs4 比用 autotools 構建 KDE 3.5.6 的 kdelibs 所花的時間少了 40%,大概是拜 CMake 不使用 libtool 組織工具鏈所致吧。在 UNIX 平台上,CMake 使用的工具鏈是這樣的:cmake+make,然後您再看看 KDE 3.5.6 的構建工具鏈:automake+autoconf+libtool+make+sh+perl+m4……夥計,對比一下吧。
這裡我準備憑自己的個人經驗來說明 CMake 到底有多好用:有一天 Aaron Seigo 向我討教怎麼把一些原屬 kdesktop 的組件轉移到 krunner 下,因為到 KDE 4 以後 kdesktop 將被全部清除。如果是在 KDE 3 下,我就得擬定一張待辦事項清單,倒不是因為代碼有多難懂,而是因為這構建系統太難應付。總之無論如何,我都不想再為 KDE 3 做這種事了。不過在 KDE 4 和 CMake 上,我只需要把代碼換個存放位置,再改幾個分類名字,這場代碼遷移就在構建系統中順利就緒了,整個過程裡只需在 krunner 的 CMake 構建文件裡修改兩到三行而已。幾分鐘後,整個項目就可以重新構建,且成功完成了鏈接和安裝。我對這件事印象很深,從此以後也致力於幫助別人做構建系統遷移 的事務。反觀在 KDE 3 時,我的腦子幾乎要被構建系統弄垮,都打算放棄,不想再把代碼往 KDE SVN 上提交了(真的不是 KDE 代碼本身的問題啊)。
事實可以表明,各位 KDE 編譯專家以後可以少死些腦細胞了,每個人都可以較輕鬆地構建他們的項目並讓其運行起來。或許有人有不同看法,但很多開發者都已經在對照了 「CMakeLists.txt」和「autotools」語法之後直截表露出和我類似的感覺。當然了,幾乎所有的 KDE 開發者現在還是 CMake 菜鳥,為此 CMake 開發者已經親身進入 KDE 群體中幫助我們儘可能順利地完成系統遷移。
這次 CMake 遷移並不是 KDE 項目第一次變更開發所需的核心技術了。在 KDE 開發早期,我們使用 CVS 實行源碼版本控制,可惜 CVS 服務器維護者的腳步開始漸漸跟不上 KDE 發展的速度,我們這裡還堆了一卡車訪問時間記錄比原始提交版本還要早的莫名其妙的代碼文件。後來我們發現 Subversion (SVN)這個全新的並行版本控制系統更加有前途,更加適合 KDE 項目的需要,也更加容易維護。當時,還沒有一個 KDE 這等規模的項目是用 SVN 管理的,對 Subversion 自己來說此次遷移也是個嚴峻的考驗,最終的結果證明了 KDE 和 SVN 能協作得很好,自 KDE 先行之後,很多別的項目也都跟著往 SVN 上遷移了。
KDE 選用 CMake 構建系統也對公眾起到了一定的示範作用,就像 Subversion 那樣。一些其它項目也在遷移到 CMake 上,其中包括但不限於: Scribus、Rosegarden(原本是 SCons)、PIPlot、ChickenScheme 等,另外我們還有項工作是讓 KDE 3.x 程序也能使用 CMake(例如 KDE 3 上的 KPilot 就已經是了)。我認為,每一個試圖支持多平台的項目都應該試試 CMake,往您的源碼樹裡加一個「CMakeLists.txt」文件不會影響既有的構建系統,反能成為體驗 CMake 能為您做些什麼的良好契機。還有,和 KDE 一樣,除非發生不可預料的意外,CMake 小組總會對產品的改進持以開放的態度。
這些鏈接可能對有興趣知道更多的讀者有用:
The original post by Alex about the port to CMake,一年多前的文章。
An earlier article on KDE + CMake,曾發表在 Linux 每週新聞上的報導。
KDE + CMake beginners guide,來自 KDE Wiki 的禮物。
這篇就到此為止。下星期,我答應給大家看些炫的東西……
原文:The Road to KDE 4: CMake, a New Build System for KDE
譯文:通向 KDE 4 之路(八):CMake,新的 KDE 構建系統
(Troy Unrau/文 | 千里孤墳/譯)
(感謝 jjgod 朋友的指正,本文已於 3/1/2007 更新。)
[轉載]通向 KDE 4 之路(七):文檔查看器 Okular 和 Ligature
過去,KDE 中包含了各式各樣的用於查看各種文件格式的程序,通過 KDE 的 KParts 技術,這些查看器在需要時可被嵌入到其它 KDE 程序(如 Konqueror 等)中。這些查看器支持的格式有 TIFF、PDF、PostScript、fax、DjVu 等等。Okular 和 Ligature 從那些早期的簡單的查看器的設計中汲取了大量的營養,逐漸步向成熟。
KDE 中早就包含了一個叫作 KGhostView 的軟件,它使用 GhostScript 作為後端,可同時查看 PDF 和 PostScript 格式的文件。 KDE 已經將其作為打印預覽工具。下面就是 KDE 3.5.6 版中 KGhostScript 的一張截圖。請注意圖中有些文字渲染失真的情況可能是與我所用的發行版中所選的字體有關,而不一定是因為 KGhostScript 渲染文件的功能有缺陷。
在 KDE 3 系列中,KGhostView 有了一個可用於查看 PDF 文件的競爭對手。這就是 KPDF,它在功能、速度等很多方面都令 KGhostView 黯然失色。現在許多發行版都將 KPDF 作為 KDE 中默認的 PDF 瀏覽器。下圖就是顯示與上圖同一文件的 KPDF。
就個人體驗來說,KDE 中的 KPDF 表現的令人驚奇。當我點擊網頁中 PDF 文件的鏈接,並指定在瀏覽器中顯示它時,KPDF 可快速而無縫地嵌入到 Konqueror 中,它表現地如此之好以至於我幾乎會忘記當前頁面不是 HTML 格式了。
還有一些高級功能如文本搜索,PDF 文件的拷貝與粘貼等 KGhostView 從來沒真的實現過。在圖層渲染,特別是加載的 PDF 文件中包含了大量矢量圖像的時候,KPDF 要快上很多。在工作中,我用到大量的地圖,這些地圖大都是 PDF 格式的,使用 KGhostView 查看時慢的一塌糊塗,您甚至可以逐條地看到地圖上那些矢量圖慢慢地顯現出來。而 KPDF 加載相同的地圖時可以做到立即顯現,這令我節省了大量的時間。
KPDF 不久前決定擴大它的文件支持範圍,而不再僅僅支持 PDF 格式了,這得感謝 Google 公司的「代碼之夏」活動的贊助。他們決定在 KPDF 中進行擴展而不是另起爐灶做個全新的軟件的主要原因是 KPDF 已經具備了大量高級功能,而在查看其它格式的文件時這些功能就不需要重新實現了。為了更準確地反映 KPDF 演化為一個可以支持眾多文件格式的查看器,它就被改名為「Okular」。
KDE 4 的用戶們面臨一個使用上的選擇,即究竟是用 Okular 還是選用 Ligature,因為兩者都被設計為支持大量的文件格式(有時它們的功能是重複的)。但因為它們都可被嵌入到其它應用程序中,無論用戶用到哪一個都會同 樣覺得高興。我將首先談談 Okular,因為我手上掌握了關於它的大量信息。在原本功能都很完備的 KPDF 的基礎上,Okular 中有了引人注目的巨大改進。目前,它看來是 KDE 4 中最好的應用程序之一。
Pin Toscano (irc.freenode.org 上他叫 pinotree) 是 Okular 的開發領袖。目前它在 KDE SVN 中開發,有興趣的朋友可以在 /trunk/playground/graphics/okular 下找到它的源代碼。它在 KDE 4 已相當穩定——實際上它是我所試用過的最穩定的 KDE 4 軟件之一。它也已被納為 KDE/Mac 軟件包的一部分。 Benjamin Reed 提交了下面這張在 Mac 中運行的 Okular 的截圖:
他提到:「真爽啊,Okular 在 OS X 中運行的很快。我可以把 Acrobat 扔掉了!:)」
我沒有測試所有它支持的文件,但根據 Okular 網站中所列出的支持格式, 它已能完全或部分支持以下 11 種文件格式:PDF、PS、TIFF、CHM、DjVu、DVI、XPS、OOo、FictionBook、ComicBook 和 s 標準圖形文件。為了所有這些格式都可完美地支持,開發工作仍在繼續中,更多的格式支持也已列上日程。Okular 將與 KDE 4 同時發佈,屆時不一定所有格式支持都啟用,這取決於那時它們的穩定程度,當然您所用的發行版也可能會作出增刪的決定。
下面這張圖是查看 ComicBook 格式的 Okular,這種格式通常用於在線發行漫畫。考慮到今後 KDE 4 可運行多個平台,Okular 甚至有可能成為最受歡迎的 ComicBook 查看程序。
Pino 很樂意與易用性小組的夥伴們共同工作以改進 Okular 的易用性,這也是 Season of Usability 項目的一部分。在 KDE 4.0 發佈之前,它的很多界面部分都將會得到幾乎是徹底地精細檢查,以使得它可以做的更好。
KDE 4 中一個可作為競爭對手的文檔查看器是 Ligature,其前身是 KViewShell。它存在於 kdegraphics 模塊中,所以它目前是它所支持的各種格式的默認查看器。但對於那些更喜歡 Okular 的人們來說,這個默認隨時都可以被推翻。我所能找到的可以使 Ligature 繼續在 kdegraphics 模塊中存在的唯一理由是「歷史因素」:其前身 KViewShell 過去本來就是 kdegraphics 的一部分。但這也不意味著 Okular 就不會被 KDE 接受:如雖然 Amarok 從不曾放在正式的 kdemultimedia 包中,但 Amarok 仍是 KDE 最好的軟件之一。
目前 Ligature 本身支持 PDF、PostScript、EPS、fax、Tiff、DjVu 等文件格式,同時 SVN 中也有支持 TeX 格式的插件。在我印象中「fax」格式與 TIFF 圖片格式有很深的關係。Ligature 的前身 KViewShell 在其主 kdegraphics 分支中還不支持上述格式中的某幾種,但在 KDE 3.5.x 分支中已加入了對上述幾種格式的支持。
我試圖弄一張顯示 PDF 文件的 Ligature 的截圖出來,但它卻不能加載 PDF 文件。我試了一個 PostScript 文件,它加載後什麼都沒顯示出來。所以我只好加載了一個實在無趣的 DVI 文件來展示 Ligature 當前的用戶界面,但它的渲染功能也只是一般。
看樣子 Ligature 與 Okular 的用戶界面很相像。這很大程度是由於它們都利用相同的標準 Qt 和 KDE 庫來繪製用戶界面部件。因為 Ligature 還不能顯示一些文檔,所以我就無法將之與 Okular 作實際的易用性對比。不過請注意,當前它還在開發狀態下,出現一些低級失誤也不必過於苛責。
關於 DVI 文件的說明:為了查看 DVI 文件,您需要安裝一些 TeTeX 文件,在我的發行版上加起來總共是 85 Mb 左右——這可能是 DVI 文件不太受歡迎的原因之一吧,雖然它的渲染能力還是很出色的。當 Ligature 在 DVI 文件中找到一個超級鏈接時,它會在文本下顯示一條下劃線以示可被點擊,這在某些場合下是很有用的,不過這種鏈接也使得文件很醜陋。Okular 就沒有加上這種下劃線,但也工作的很好。
Okular 與 Ligature 使用了不同的內部構架,實現了相似的效果,但它們內部所依賴的底層庫是相同的(就像 MPlayer 和 xine 內部千差萬別,但它們都使用相同的底層庫來解碼)。這就意味著它們不太容易合併為一個項目,而對底層庫的跟進開發則可同時使得兩個程序都受益。 Okular 將會被各個發行版單獨打包,而由於現在很多發行版最終都會把 kdegraphics 分解為若干個包,Ligature 就將會是這些軟件包中的一個。當然了,只要也安裝了必要的 KDE 庫,GNOME 用戶們也可以正常地使用 Okular 和 Ligature。但他們也可以使用共享底層庫的 Evince,而 Evince 與 GNOME 環境集成的更好。
本週的內容就是這些。希望可以澄清關於 Okular 和 Ligature 的混亂。
原文:The Road to KDE 4: Okular and Ligature Document Viewers
譯文:通向 KDE 4 之路(七):文檔查看器 Okular 和 Ligature
(Troy Unrau/文)
(yuanjiayj/譯)
轉載自 通向 KDE 4 之路(七):文檔查看器 Okular 和 Ligature
-2007/3/12-------------------------------------------------------------
已經將本篇文章的圖片轉至本Blog上了,圖片已經可正常顯示。
[轉載]通向 KDE 4 之路(六):令多媒體技術更輕鬆的 Phonon
Phonon 是一項新的 KDE 技術,它為多媒體程序播放音頻或視頻時提供了一套應用程序接口(API)。這套接口被設計成 Qt 函數的風格,這樣 KDE 開發者們使用它時就不會覺得很陌生了。(如果您對 Phonon 的 API 感興趣的話,請看看這些在線文檔,這些文檔可能還是最近更新的,不過不能保證)。
首先要指出的是 Phonon 不是一個新的音樂系統服務器,它不會與 xine、GStreamer、ESD、aRts 等構成競爭關係。相反,由於這些多媒體程序接口常常會不斷變動,Phonon 以這些其它多媒體技術為後端,提供了一套不變的 API。這樣就方便了,比如當 GStreamer 的 API 改變了,只要 Phonon 做相應的調整就可以了,其它使用 Phonon 的 KDE 程序都不會受到影響。
Phonon 的功能來源於開發者們所謂的「引擎」,每一種引擎支持一種後端。目前開發中的引擎有四種:xine、NMM、GStreamer 以及 avKode(aKode 的繼承者)。可以肯定的是 aRts 光榮退休了,針對它的引擎是不會被開發的了。不過 aRts 還會在其它領域繼續存在的。KDE 4.0 的目標是實現一個「保證可用」的引擎,外加一些可選用的引擎。
已被建議開發的引擎還有 MPlayer、DirectShow(在 Windows 平台上的)和 QuickTime(在 Mac OS X 平台上的)。這些額外的引擎的開發工作還沒開始,因為 Phonon 的核心開發者們更關心的是確保目前開發的這個 API 功能完備。如果 Phonon 的開發者在當前這個 API 還很垃圾的情況下,就去忙於其它引擎的編寫工作,那整個項目不亂套才怪呢(如果您想要出力編寫一個引擎的話,請到 irc.freenode.org 的 #phonon 露個臉吧)。
當用戶或程序選用了某個引擎之後,Phonon 就會使用這個已選中的引擎來確定各個後端所支持的文件格式和解碼器,然後自動允許 KDE 程序播放多媒體文件。目前的 KDE 3 系列中,用戶不得不手動在各個程序(如 Kaffeine、Amarok、Juk 等)中更改引擎,而不是通過 KDE 來選用引擎。
一旦 Phonon 選定了引擎,它就會使程序配合該引擎進行標準的多媒體運轉。這裡的標準的多媒體運轉包括媒體播放器中常用操作,如播放、停止、暫停、尋找等。Phonon 也支持更高級的功能,如定義兩個音軌之間跳轉的方式等,這樣不同的程序就可以共享這項功能而不用每次都去重新實現它。當然,一些程序想要在跳轉時能有更多 的控制,自己設計也沒什麼不可以的。
目前各個引擎中完成進度都好的是 xine,我在我的電腦上已經裝上去並可以工作了。我也嘗試過編譯 NMM(出了名的難編譯、難安裝)和 GStreamer 引擎,可惜沒有成功,另外那個 avKode 默認就是「停用」。我本來還想拿幾張 Juk 或 Noatun 採用 Phonon 播放音頻的截圖出來貼一下,但它們與 KDE 3 系列版本中看起來也沒什麼兩樣(有些界面還更醜一點!)。等它們漂亮點的時候,我就在後續文章中把它們貼出來。
Matthias Kretz 提供了一個較短的視頻文件,說的是在看電影時打開您的揚聲器,驗證設備的切換。Phonon 可以使您的原音頻設備在切換後停止工作,從而您可以聽到聲音突從耳機中消失而在音箱中響起。
Matthias 也提供了下面這張使用 Phonon 設置模塊選擇輸出設備的截圖。這還在改進中,所以看起來還很粗糙。
很難用截圖來反映 Phonon 的工作情況(音頻框架的截圖實在難搞),但我可以描述下使用 Phonon 之後靈巧的一面:網絡透明化。KDE 使用 KIOSlaves 來訪問網絡上的文件,這輕鬆的好像這些文件在自己的電腦上一樣。多媒體程序如 JuK 或 Amarok 也能夠在自己的收藏中非常透明地共享網絡音頻文件,開發者在實現這個功能時還不必去考慮後端引擎是否明白如何與 ioslaves 互操作這個問題。這項功能在 KDE 4 中已經部分地實現了,已可通過音頻縮略圖進行可視化操作了。很多人都可以使用任何 KIO 協議,包括 sftp:// 和 fish:// 這兩個 KDE 強人們非常喜歡的協議進行文件共享。在我的電腦上自行編譯的 fish://KIOslave 還很不穩定,不過據 #phonon IRC 上的開發者宣稱,這個功能的將很快結束編寫並投入使用,屆時它的穩定性就沒問題了。
正在開發中的 Phonon 將成為 KDE 程序的一項支柱性技術,它會使開發者的工作更輕鬆,並可避免多媒體後端的變動對各應用程序帶來繁雜工作以及不穩定性,更使得 KDE 程序對其它平台的支持變得輕而易舉。這就意味著那些開發者們可以在他們程序的其它部分花更多的時間,KDE 多媒體程序也將會變得比現在的更出色。
一些小消息:Amarok 的首席開發者 Mark Kretschmann 在本週正式開始了對 Amarok 2.0 的開發,而且他對 Phonon 對 Amarok 2.0 能起到的作用很感興趣。Amarok 開發小組還是與他們在 1.4 系列版本中做的那樣,還在開發自己的引擎。不過,就 Phonon 目前的開發狀態來說,Phonon 還是可以通過調整來滿足 Amarok 的需要的。
Phonon 開發者們的老大 Matthias Kretz 正在尋找有人可以為 Phonon 維護他們的網站,如果您想在非編程方面幫助 KDE 的話,不妨考慮一下。
原文:The Road to KDE 4: Phonon Makes Multimedia Easier
譯文:通向 KDE 4 之路(六):令多媒體技術更輕鬆的 Phonon
(Troy Unrau/文 yuanjiayj/譯)
-2007/3/12-------------------------------------------------------------
已經將本篇文章的圖片轉至本Blog上了,圖片已經可正常顯示。
[轉載]通向 KDE 4 之路(五):Kalzium 和 KmPlot
我們的諸多教學工具軟件在 KDE 4 的整體發展中已經進行了很多的工作,在這其中 Kalzium 和 KmPlot 的進展又尤為迅速,它們的變化之大簡直令人驚訝。
Kalzium(對應的德語單詞是 Calcium)自 KDE 3.1 開始就是標準發行中的一個組件,現在它已經是 KDE-Edu 小組開發的眾多程序中用戶最多的產品之一。最初它只是一個用於顯示化學週期表的程序,至多一旁再顯示著幾個如原子量、沸點這樣的科學數據。但在不久之後, 它逐步拓展加入了許多元素背景方面以及更多細節上的化學信息(如光譜圖),這就使得它在化學相關的一些應用場合越來越實用。
在 KDE 3.5.5 中(這是我抓圖時所用的版本,然而本週 3.5.6 也該發佈了),Kalzium 在第一次啟動時的樣子是這樣的。
您可以發現這個界面相當簡單,但卻展示了很多的信息。如果您在任意元素上點擊,還將會有更多的元素屬性被陳列出來。
在 KDE 4 中,程序的主界面將會有所不同。除了 Qt 4 為我們引入了一些觀感上的差異以外,還有些圖標被改置到了工具欄(圖中有些沒顯示出來)。在此讓我們先窺視一下 KDE 4 開發分支下的 Kalzium 的模樣。
Kalzium 將來要達到的視覺效果會和圖示的越來越接近。然而,在這 KDE 4 抓圖中最值得矚目的一點是工具菜單,在 KDE 3.5.5 中,這個菜單只包含「繪製數據」和「專業詞典」兩個項目(譯註:這裡說錯了,完整的工具菜單還應包括「化學方程式配平器」這條,但因 Ocaml 依賴的緣故這個功能在很多預編譯包中都不提供)。
「繪製數據」的用途是以多種模式來繪製一個元素的坐標圖,例如可以基於質量、原子半斤、電負性等模式來工作。而「專業詞典」則能給出許多常用化學專 業用語的精確定義,不過上面提到的「電負性」一次似乎被遺漏了……總之,很顯然這個程序還有充分的改進空間,而對於「專業詞典」的改進將為 KDE 4 中的 Kalzium 提供一個能促進非程序員的化學愛好者也能為其作出貢獻的良好契機。
不管怎麼說,還是讓我們先回過來看看一些新的工具,我將著重介紹這些新開發出的東西,它將使 Kalzium 在 KDE 4 中變得更加有用。
新的 Kalzium 將有一個同位素表能為您顯示出一份同位素的清單及其衰變模式──假設我是一名地質師,認識到鉀-40 這種物質通常會因為電子俘獲而產生衰變可是非常重要的事項。
新的化學方程式配平器也相當值得一用,正如現在的 Kalzium 項目開發領導 Carsten Niehaus 給我們帶來的這張抓圖所顯示的那樣:
基本上您只需要在配平方程式時寫上正確的字母,您所期待的相應數字就會被程序反饋出來。在高中的化學授課中,學生往往被要求手動去解出一連串的方程 式,但就像大多數方程式那樣,一旦您解過很多方程式,會感到這種任務越來越乏味,這種時候這個方程式配平器將會為您節省下很多本該用於處理那些複雜的方程 式的時間。
最後,未來的 Kalzium 最值得注意的改變莫過於 Kalzium 裡的三維效果,程序會藉此擁有一個三維的分子查看器。這個機制本來是由 Kalzium 的開發者所設計並打算只用於這個程序,但是一些協作開發者也將其納入了 libavogadro 函數庫,這樣 Kalzium 和 Avogadro 的開發者將會一起共同研發這個特性。
根據 Kalzium 開發者們當前的進度描述,現在要做的事是通過 libavogadro 函數庫去移植 3D 建模器,Donald Curtis 正致力於這項工作,這將提供一個基於 Qt 和 OpenGL 的更通用更強大的分子渲染生成引擎,工作成果將被 Kalzium 和 Avogadro (或許更多)共同享用。Avogadro 是一個更高階的分子建模程序,可被用於創建真實的分子文件以及量子化學領域,Kalzium 3D 將只是單純地作為一個能查看此程序所構建的圖像的查看工具。
Kalzium 的開發者 Benoît Jacob 提交了一幅抓圖來展現使用了 Kalzium 3D 功能的三維分子查看器工作狀況預覽。在本文發表時,此功能已經進入了 SVN 代碼倉庫,當然它是和 libavogadro 函數庫集成運作的。
Kalzium 以後有可能會和一批由 BlueObelisk 項目提供的常見分子數據共同發佈以供您查看,感謝 OpenBabel 項目,它可以幫助我們能去打開一大批各種各樣的分子文件格式(據統計已支持文件格式就達 62 種)。
現在輪到了下一個 KDE-Edu 成員:KmPlot。正如現在已知的那樣,此應用程序具備繪製一般函數圖、參數函數圖還有極坐標函數圖的能力,還有一些衍生的顯示功能和的其它趣味特性。 它是一個頗有用的的方程式繪圖工具,只是現有的界面未免太拙劣了,甚至還有很多凌亂的對話框會充填屏幕空間。
下面您所看到的是 KDE 3.5.5 中使用默認設定的 KmPlot 啟動界面,上面已經繪製了三個函數,每個的形狀都不同:
這個對話框是用於撰寫像上面的那樣要繪製的函數式的,不過對每一個函數形狀都會有一個獨立對話框。
這裡還有一張新版 KmPlot 的界面一瞥,上面同樣繪製了那三個函數圖,不過不會再有那麼多對話框來佔據空間,而且加上 Qt 4 提供的精緻的反鋸齒觸感,這些線條甚至可以和方形一樣平滑!
對 KmPlot 的工作現在正緊鑼密鼓地開展,我們相信它將會成為 KDE 4 的殺手級程序之一,無論是學生還是工程師還是其他人都有理由喜歡上它。現在它甚至可以繪製微分函數,而且擁有了一個新設計的函數編輯器,並且會為您提供如 何校正函數式的即時提示(如上圖所示)。
新的函數編輯器如下圖所示,對微分函數的編輯支持也包含其中:
如您所見,現在輸入函數式會比以往更加簡單,當您在操作時函數編輯器還會實施友好的語法檢查。在本文中還有許許多多 KmPlot 的進步沒有被提到,如果您有興趣瞭解更多消息,請查閱這個開發狀態頁面。
總的來說,KDE-Edu 還是一個成長中的項目,許多優秀的應用程序是涵蓋了各個年齡層的開發組的產物,它們還需能支持 Windows 和 Mac 操作系統,要感謝 Qt 4 的改進與 KDE 4 類庫能讓這些程序更加大眾化。現在,還有不少很棒的工作在不斷取得進展,請期待以後的文章為您帶來更多的 KDE-Edu 軟件巡禮。
原文:The Road to KDE 4: Kalzium and KmPlot
譯文:通向 KDE 4 之路(五):Kalzium 和 KmPlot
(Troy Unrau/文 千里孤墳 /譯)
轉載自 通向 KDE 4 之路(五):Kalzium 和 KmPlot
-2007/3/12-------------------------------------------------------------
已經將本篇文章的圖片轉至本Blog上了,圖片已經可正常顯示。
[轉載]通向 KDE 4 之路(四):新的工作進度管理器
設想下 Firefox 的下載管理器與 KDE 的打印隊列管理器,除了工作類型外並沒有什麼實質上的差別。每個 KDE 4 程序在有任務時都會在一個進度管理器對話框內添加一個叫作觀察器(Observer)的標記。然後這個獨立的程序就能觀察到任何正在進行中的任務了,並且 能像原來的進度對話框那樣顯示進度甚至添加某些可回饋到原程序的操作按鈕(如「取消下載」等)。有些程序如 K3b,它已具備了非常良好的進度報告系統,那它們的對話框就會保留下來,但其進度仍將被新的進度管理器觀察到,於是所有的任務進度條都被放在了同一個地 方。
在 Rafael Fernandez Lopez 的努力下,工作進度管理器原本作為一項虛擬的 KDE 4 改進設想通過 KDE-Look.org 逐漸成為一個功能完備的 KDE 4 整合項目。大量程序已通過修改支持了這個新管理器,很多的進度條集合在了一起。上週二的「二進制不兼容變化」日中,大量的改變被正式地提交到 KDE 4 倉庫中了。
下圖是 KDE 用戶及 KDE-look.org 的貢獻者 kiras 所製的原始模擬圖。
應注意的是上圖還只是個模擬圖,並不是 KDE 4、Plasma 或 Konqueror 的最終的真正的樣子。
目前它已被做成一個標準的系統托盤程序(就像 KDE 3.5.5 中的打印隊列管理器那樣),它與 GNOME 的托盤可相互配合使用。但它目前還只能觀察到 KDE 程序,所以目前監視 Firefox 的下載進度還不支持。不過也不能說以後不會支持,因為使用 D-Bus 交互進程通訊構架後非 KDE 程序的進度應該是能被觀察到的。目前已有意向與 GNOME 下的 Mathusalem 團隊合作開發了,這是個類似的項目。
下圖是目前已實現的監視程序的截圖,只要點擊下托盤圖標,它就會顯示出來。您可以看到,它已經相當實用了。
您可以看到 Kopete 的按鈕位置已被預留住了,它還沒什麼意義只是為了做測試用的。不過只要你點擊某個按鈕中的,它就會回傳給 Kopete 一個信號,然後 Kopete 就跳出一個更小的對話框。
您所看到的 Konqueror 的下載進度條顯示的是一個真實文件的下載進度。當 Konqueror 關閉後,它們仍會繼續工作。而像「中斷下載」之類有用的操作按鈕正在實現中。
如果您想要參與 KDE 4 的開發工作,為 KDE 程序添加新的 Kjobs 進度監視支持是相當容易的切入點。它只需要幾行代碼就可以使得應用程序在進度管理器上顯示進度,也只要幾行代碼就可以實現操作按鈕的功能。
這個新的進度監視技術將整合入 Konqueror(如模型中的那樣)、桌面托盤程序,其它程序將直接使用 D-Bus。我甚至可以想像到一個小的網絡程序可以讓您遠程監測進度……
Rafael 的目標是在最初的功能實現之後,就添加項目保留功能,這樣當一個工作結束之後,它就可以隨意地保留在隊列中直到被用戶關閉為止。他也在尋求人們對這個工具的反饋以及可實現的改進。
期待有更多的文章羅列出 KDE 4 偉大的技術。
方法論上的一個小便條:我確保在我的截圖上使用 KDE 默認的風格,即使它很醜陋我也要這麼做,因為這樣你就可以對 KDE 的進展有一個更好的理解並可以清晰地看到它的進步。另外作為一種準則,我到目前為止所演示的各種特性都是可用的,任何人都可以通過下載 SVN 上的源代碼進行編譯安裝重現我的演示。而今天的文章,我不得不弄了一些簡單的代碼以使這個正在開發中的程序可用,這是我一直堅守的準則的一個例外。另外, Kopete 進度支持還沒放入官方的 SVN 庫,但 Rafael 已用它來測試特性了。
原文:The Road to KDE 4: Job Progress Reimagined
譯文:通向 KDE 4 之路(四):新的工作進度管理器
(Troy Unrau/文 yuanjiayj/譯)
已經將本篇文章的圖片轉至本Blog上了,圖片已經可正常顯示。
[轉載]通向 KDE 4 之路(三):完全的 Mac OS X 支援
在我講述之前,我想先討論幾個 KDE 必將面對的一些問題。在 KDE 3 中,KDE 這個術語指的是 KDE桌面環境(Kwin、Kicker、kdesktop 等),由此當它面向 Mac OS X 的版本中不再出現這些組件時它還有理由被稱為「KDE」嗎?或者 KDE 是指這整個項目,按這種說法,無論 Konqueror 是否運行於 Mac、Windows 或者 Enlightenment 等平台,它都可被稱為一個「KDE 程式」。
有一些關於 KDE 4 的問題已被討論過了。討論的結果是「KDE」就像一把大傘,它包括 KDE 的所有東西。也就是說 KDE 應用程式,KDE 開發環境(庫以及技術),KDE 工作空間(由 KWin、Plasma 等組成),這三個主要部分組成了 KDE 軟體。當我們談及 KDE 時,它所指的就是全部。
這種說法也解決了一些有著獨立發佈時刻表的軟件所帶來的問題。例如 Amarok 有一個與 KDE 不同的時刻表,於是有一些人就不把它看作是 KDE 整體的一部分。在 KDE 4 中的 Amarok 清楚地被標為是一個可限制性運行於某桌面環境中的「KDE 程式」,而不存在任何的隱晦。在 KDE 4 中,雖然 Amarok 有獨立的開發週期,但它仍是一個 KDE 產品。正如 Amarok 的首席開發者 Mark Kretschmann 所說的,「如果 Amarok 使得更多的用戶去使用 KDE 技術的話,那就很理想了。如果有人在其它平台上如 GNOME 或 Mac 上使用它的話,對我們來說也不錯。」
本文說的是非運行於 X11 平台上的 KDE,所以我們需要先將 KDE/X11 與 KDE/Mac 區分一下。在詢問了一些開發者後,我採用這種說法:KDE/X11 指的是所有 KDE 程序運行於 X11 上,開發環境搭建在 X11 上,KDE 工作空間也在 X11 上。同樣的,KDE/Mac 是指 KDE 程序運行於 Mac 上,KDE 開發環境搭建在 Mac 上,而 KDE 工作空間則不存在於 Mac 上,這裡沒有包括它。以上說法同樣適用於 Windows 平台。然而必須知道的是這些所謂的區別僅僅在於平台不同,最重要的是 KDE 原始碼是相同的,並沒有為某個平台將原始碼樹分開。不存在分支或者異樣的端口。
新的 KDE 開發環境技術如 Phonon 和 Solid 可使移植變的輕鬆,因為與平台的整合工作發生在庫的水平上。KDE 程式的開發不必太在意操作平台的不同。
什麼是 KDE/Mac?
KDE/Mac 是可原生執行於 Mac 操作系統上的 KDE 程式的集合,包括使這些 KDE 程序工作的底層技術,庫等。KDE/X11 與 KDE/Mac 只有略微的不同。最大的不同是 KDE 工作空間如 KWin 和 Plasma 等不會在 Mac 上出現。原因是 KWin 和 Plasma 的功能在 OS X 系統中已經存在,強行地在 Mac 系統上實現它們會造成 KDE 程序與其它 Mac 程序不能很好的整合在一起。因此 KDE 就沒有把 KDE/X11 移植到 Mac 中去了。
在 KDE 設計之初就考慮到 KDE 程序與其它 UNIX 桌面環境(早期是指 Window Maker,後來是 GNOME 和 Enlightenment)共存的問題。KDE 程序用的是共享的標準(如 FreeDesktop.org 的成果),可共享剪貼板數據、系統托盤,所以與其它平台的兼容問題較少。而現在由於 Qt 4 所帶來的高度可移植性,在如 Mac 等非 X11 環境中 KDE 的兼容性也很好。
KDE 程序以前就能運行於 Mac 平台上,它可使用蘋果公司建立在 OS X 系統上的 X11 服務層,但因為 KDE 仍然使用 Qt/X11,所以這些程序看起來與運行在普通 X11 平台上的樣子差不多。事實上它們能良好的運行, Fink 項目的出色成果功不可沒。如果您有興趣在 OS X 系統運行其它 UNIX 程序的話,去看看 Fink 項目吧。
(其實也存在一個 Qt/Mac 的自由軟件版本可以在 Mac 平台上使用 KDE 3.x 系列的程序,但由於穩定性的原因,通常還是使用包含 Fink 技術的 KDE/X11。)
下面是一張用 Fink 技術將 KDE 3.5 運行於 Mac 系統的截圖。
由於建立在 Qt/X11 平台上,這使整個 KDE 環境都能夠運行。但可明顯的發現 KDE 與 Mac 系統沒什麼協調性,就好像是在一個屏幕上運行了兩個完全不同的計算機系統。
KDE 4 則在移植工作中取得了巨大的進步,這很大部分要歸功於 Qt 4,還有基於 CMake 的新的 KDE 構建系統。在「KDE on Mac OS X」網站上 KDE/Mac 程序的 .dmg 文件已作為一個標準發佈包提供下載。多虧了 KDE/Mac 項目的頭兒 Benjamin Reed,KDE 開發快照版可以很容易地運行在 Mac 平台上。請訪問 irc.freenode.org 的 #kde-darwin 頻道幫助報告和解決問題。現在 KDE 4 還遠沒到可發佈的程度,它還很可能崩潰。
已下載的軟件包被打開並被安裝之後,KDE/Mac 程序可以使用 OS X 的 Finder 運行,如下:
從上圖可以看到大量的 KDE 程序已可以在 Mac 上使用。由於這還是一個開發中的版本,有些程序很容易崩潰(就像使用 SSL 的程序)還有些東西看起來很醜陋。在這點上,目前運行於 X11 上的 KDE 4 也是同樣的,希望 KDE 4 的開發可以在這兩點可以同時改進。
在移植的同時,一些非常重要的工作也發生在 KDE/Mac 的整合中。例如,剪貼板,鍵盤快捷鍵,其它語言輸入等。還有鼠標拖放仍然很粗糙。KDE/Mac 的開發者們需要任何瞭解 KDE 和 Mac 技術的夥伴來幫助他們解決這樣的小問題。
這就是你們所期待的:在截圖中大家都看到了目前 KDE 4 移植工作的進展情況。Mac 用戶對其中的一些程序也是讚賞有加。
由於我們使用 SVG 技術,我就先貼一張在 Mac 平台上的 SVG 截圖。下面是 Shisen Sho,這是一個板塊遊戲。Shisen Sho 與 KMahjongg 共享了 SVG 板塊。這個遊戲在 Mac 上看起來很漂亮,風格也很一致。
上週有人問起 KOffice 是否也支持其它平台。我現在可以愉快地告訴你們,KWord、KSpread 以及 KOffice 的其它組件在 KDE/Mac 上運行的很好。我在上週測試了開發中的 KOffice 2,KWord 與它在 KDE/X11 中的版本運行的一樣好。同時我還運行了其它一些 KOffice 程序看它們是否工作。下面是一張運行於 Mac 系統上的 KSpread 嚮導及 KDE4 文件對話框的截圖。
還請注意下 KSpread 圖標在 OS X 底欄上的顯示。它可不像運行於 Fink 技術上的 KDE 那樣(在桌面左方會出現一個 KDE 邊欄),可調置為自動隱藏。已運行的程序圖標顯示在邊欄上。
當然也許有人會問:Konqueror 能運行嗎?答案是可以。KDE 4 版本的 Konqueror 主要是 KDE 3.5 中的 Konqueror 的移植工作,但其後端庫如 KHTML 渲染引擎和 Javascript 支持都獲得了大量的改進。在 Mac 上,由於 Qt 4 實現的 OS X 風格,我們使用的是當中的標籤瀏覽,如下:
Mac 自稱是圖形與多媒體程序第一平台。但此快照版中沒有找到 KDE 圖形包,所以我就不能抓張圖出來看看了。
但 education 包裡的小程序還是可以讓 Mac 顯露一點鋒芒的。下面是包含在 KDE-Edu 項目中的兩個優秀的程序:Kalzium 和 KStars。在 KDE-Edu 項目中的新特性容我以後介紹。現在還是讓我們看看 KDE/Mac 中的這兩個華麗而又功能完備的程序。
圖片就貼到這裡了,當 KDE 運行於其它平台時,就總會出現一些其它問題的。
當我考慮這篇文章的時候,我遇到很多人,它們反對在一個非自由平台上運行 KDE 程序。他們在 IRC 上露出這樣的情緒「無論何時你在一個非自由的平台上運行自由軟件,上帝就會殺死一隻小動物。甚至會殺死一隻伶俐的小動物。」
但 KDE 有其支持其它平台的好理由:吸引開發者,鼓勵互操作性以及形成標準。世界上有大量的 Mac 和 Windows 的開發者,支持了 Mac 和 Windows 就可以使大量的程序利用 KDE 技術。支持其它平台使 KDE 技術受益的最好例子是 KHTML/WebKit。現在世界上有很多用戶使用基於 KHTML 的網絡瀏覽器,各網站不得不提高他們與標準的兼容性,這就意味著更多的網站使用 Konqueror。同樣的事也將會發生,如 KOffice 之與 OpenDocument 格式,Kontact 之與自由軟件組件系統,這都將是雙贏的。
原文:The Road to KDE 4: Full Mac OS X Support
譯文:通向 KDE 4 之路(三):完全的 Mac OS X 支持
(Troy Unrau/文 yuanjiayj/譯)
轉載自 通向 KDE 4 之路(三):完全的 Mac OS X 支持
-2007/3/12-------------------------------------------------------------已經將本篇文章的圖片轉至本Blog上了,圖片已經可正常顯示。
[轉載]通向 KDE 4 之路(二):新 KOffice 技術
KWord 與 Kexi 不同,作為一個 KDE 軟體,它一直都被籠罩在巨大的 OpenOffice.org 軟體的陰影之下。但這種情況將會得到改變,新的 KDE 4 技術將可使它作為原生程序的形式執行如 Windows 和 Mac OS X 等其它平台下。您可以從一些文件中找到 KDE 4 程序對其它平台的支援方面的詳細情況。
KOffice 和 KWord 的最大的一個功能是對 OASIS OpenDocument 格式標準的支援,這種格式被眾多辦公軟體(如 OpenOffice.org、Google Docs)採用。目前開發者們正全力工作以求在 KWord 中獲得對 ODF 格式的全面支援。
讓我們看一下正在開發中的 KWord。請注意界面中各個方面中良好的圖形保真效果。在我的系統中,它並不比 KOffice1.6.1 執行得慢。KWord 2 中獲得最多改善的地方是它的文件格式與排版功能,這個功能也特別值得推薦。雖然它的開發還在繼續中,但您從下面這張圖中可以發現它比以前的版本要進步很多。您真的需要親自體驗一下新版本中移動、縮放以及旋轉圖層等操作時有多地流暢。
加入 KWord 中的所有對象都會被轉化為新的圖層庫,如 KFormula 所生成的公式,您可以在 KWord 中準確無誤地插入做好的數學公式。這使得 KWord 可以像 KPresenter 那樣輕鬆地進行頁面排版,因為您不再受制於呆滯、規矩的文件格式。這些改變將使得 KWord 2 成為受注目的基礎桌面排版程序。
另外在早期版本中缺少拼寫檢查支持的現象將得以改善,我們將使用 Sonnet 來完成拼寫、語法檢查。(在我的截圖中沒找到拼錯了的單詞吧?)
但這也不是 KOffice 2 中唯一的改進。例如在 KOffice 2 中我們還加入了新的擴展腳本嵌入框架 Kross。開發者們已為它做了很多的工作,而它也將是 KOffice 2 中的一個殺手級特性。
注意圖中我是如何打開子工具欄的。我直接通過拖放就讓它自動出現了。這是 Qt 的新特性,這樣操作不會造成明顯的界面不穩。
當然 KOffice 的其它組件也能應用腳本嵌入和圖層特性。KSpread 和腳本功能結合的很好,對進階用戶來說它實在是太強大了。
對 Kross 有興趣的朋友可以看看關於 KSpread 中 Kross 的開發與應用的這篇文章:http://wiki.koffice.org/index.php?title=KSpread/Scripting。
這只是在 KDE 4 平台上執行的 KWord 和 KOffice 中大量改進工作中的一部份。當然這些截圖展示的還只是開發中的版本,它還不太穩定,但在開發者的頻道(如 irc.freenode.org 中的 #koffice)中穩定性是反覆強調的。在新版本發佈之前還有大量的幕後工作要做。
KOffice 有獨立的發布時程表,所以它也許不會與 KDE 4 同時發佈。
原文:The Road to KDE 4: New KOffice Technologies
譯文:通向 KDE 4 之路(二):新 KOffice 技術
(Troy Unrau/文 yuanjiayj/譯)
轉載自 通向 KDE 4 之路(二):新 KOffice 技術
-2007/3/12-------------------------------------------------------------已經將本篇文章的圖片轉至本Blog上了,圖片已經可正常顯示。
[轉載] 通向 KDE 4 之路(一):SVG 透視技術
自從 KDE 4 的開發全力進行,而 KDE 4.0 版將在今年稍後一點的某個時間發佈。我想是時候整理出一個名叫通向 KDE 4 之路的每週欄目了。這個想法大致是把 KDE 4 有進步的幾個特性分期做幾個簡短的回顧。這是第一期,目的是將偉大的 SVG 透視技術目前所得到的結果呈現於大家的面前。下面是詳細內容。
很多的新特性已通過 KDE Planet 的眾多個人博客為人所知,而我就打算寫點大家不太知道或是需要大家多瞭解的內容。
首先我想要告訴大家的是 KDE 的構建,安裝和運行等方面已相當好了,我已測試了很多從 KDE 3.x 中移植過去的程序了,大多數程序都非常穩定。當你親眼看到底層技術的進步所引起的那些改變的時候,那是真正令人非常開心的。今天我將介紹的是由 Qt 4 中的 SVG 透視技術所帶給人們的感觀享受。
很多其它 KDE 程序正在運用 SVG 技術所帶來的好處,這會讓它們更令人愉快。你可以從 http://tsdgeos.blogspot.com/2006/12/svg-meets-blinken.html 和 http://wiki.kde.org/tiki-index.php?page=KDE+Games+SVG+status 找到很多有關信息。
今天我將把一些 KDE 3.5.5 中的一些軟件和 KDE 4 中的對應軟件的截圖拿出來作個對比。
首先我們看到的是 KDE 系統守護軟件( KDE System Guard),它是 KDE 中一個很有用的工具。你可以輸入「ksysguard」來運行它。它收集了各種簡潔的底層信息,如內存和 CPU 使用表以及進程表等。
下面是 KDE 3.5.5 中它的樣子:
而現在 KDE 4 的開發版中它是這樣的(線條是抗鋸齒的,圖表是半透明的,背景是 SVG):看到了吧,這種改進是否很有意思呢!
下一個,我們看到的是 kdegames 中的幾個軟件。首先出場的是 KAtomic,這是個迷宮類的遊戲,它很有趣,也有半教育性,它也用 SVG 技術改進了。看看對比吧。
而在 KDE 4 中它具有了 oxygen 風格:
接下去出場的是 KMahjongg,它也算是一個迷宮遊戲吧。它在 KDE 3.5.5 中的樣子與 Windows 娛樂包中的一個軟件的樣子很像。
而 KDE 4 中,經過 SVG 技術改進後,麻將牌變成了這個樣子:
最後要介紹的是一個很常用的 KDE 組件:「運行命令」對話框(Alt-F2),KDE 3.5.5 中它是這樣的:
而現在,在桌面界面設計中的大師 Aaron Seigo 的指導下,它成為了 Plasma 桌面中一個 SVG 主題式,優雅的組成部分。它還是個半成品,但下面的截圖中會讓你感受到這個創意的。
原文:The Road to KDE 4: SVG Rendering in Applications
譯文:通向 KDE 4 之路(一):SVG 透視技術
(Troy Unrau/文 yuanjiayj/譯)
轉載自 通向 KDE 4 之路(一):SVG 透視技術-2007/3/12-------------------------------------------------------------
已經將本篇文章的圖片轉至本Blog上了,圖片已經可正常顯示。