Qt、GTK 和KDE、GNOME的關係
Linux 下的圖形庫介紹
在進行Linux下的圖形系統程式設計時,我們常常會遇到以下這些概念:
Framebuffer, X11, SDL,DFB, miniGUI, OpenGL,QT, GTK,KDE, GNOME等等。
一、Linux 圖形領域的基礎設施1.1 X Window
X Window從邏輯上分為三層:X Server、X Client和X協議。
最底層的X Server(X伺服器)主要處理輸入/輸出資訊並維護相關資源,它接受來自鍵盤、滑鼠的操作並將它交給X Client(X客戶端)作出反饋,而由X Client傳來的輸出資訊也由它來負責輸出;
最上層的X Client
X協議則是銜接X Server與X Client的通訊協議,它的任務是充當這兩者的溝通管道。儘管UNIX廠商採用相同的X Window,但終端的X Client並不相同。
XFree86是X Window系統的一個開源的實現。它主要運行於Unix以及類Unix作業系統上。XFree86在顯示硬體(滑鼠、鍵盤以及顯示卡)與桌面環境(也就是視窗管理器)之間提供了一個Client/Server介面。
1.2 SVGALib SVGALib是Linux下的底層圖形庫,也是Linux系統中最早出現的非
1.3 FrameBuffer FrameBuffer是出現在Linux 2.2.xx核心當中的一種驅動程式介面。這種介面將顯示裝置抽象為幀緩衝區。使用者可以將它看成是顯示記憶體的一個映像,將其對映到程序地址空間之後,就可以直接
1.4 LibGGI LibGGI試圖建立一個一般性的圖形介面,而這個抽象介面連同相關的輸入(滑鼠、鍵盤、遊戲杆等)抽象介面一起,可以方便地執行在X Window、SVGALib、FrameBuffer等等之上。建立在LibGGI之上的應用程式,不需重新編譯,就可以在上述這些底層圖形介面上執行。但不知何故,LibGGI的發展幾乎停滯。
二、Linux 圖形領域的高階函式庫 2.1 Xlib及其他相關函式庫 在X Window系統中進行圖形程式設計時,可以選擇直接使用Xlib。Xlib實際上是對底層X協議的封裝,可通過該函式庫進行一般的圖形輸出。如果你的X Server支援DGA,則可以通過DGA擴充套件直接訪問顯示裝置,從而獲得加速支援。對一般使用者而言,由於Xlib的介面太原始而且複雜,因此一般的圖形程式選擇其他高階一些的圖形庫作為基礎。比如GTK、QT 等等。這兩個函式庫同時還是一些高階的圖形使用者介面的支援函式庫。由於種種原因,GTK、QT等函式庫存在龐大、佔用系統資源多的問題,不太適合在嵌入式系統中使用。這時,你可以選擇使用 FLTK,這是一個輕量級的圖形函式庫,但它的主要功能集中在使用者介面上,提供了較為豐富的控制元件集。 2.2 SDL SDL(Simple DirectMedia Layer)是一個跨平臺的多媒體遊戲支援庫。其中包含了對圖形、聲音、遊戲杆、執行緒等等的支援,目前可以執行在許多平臺上,其中包括 X Window、X Window with DGA、Linux FrameBuffer控制檯、Linux SVGALib,以及Windows DirectX、BeOS 等等。 因為SDL是專門為遊戲和多媒體應用而設計開發,所以它對圖形的支援非常優秀,尤其是高階圖形能力,比如Alpha混和、透明處理、YUV覆蓋、Gamma 校正等等。而且在SDL環境中能夠非常方便地載入支援OpenGL的Mesa庫,從而提供對二維和三維圖形的支援。 可以說,SDL是編寫跨平臺遊戲和多媒體應用的最佳平臺,也的確得到了廣泛應用。相關資訊,可參閱 。 2.3 Allegro Allegro是一個專門為x86平臺設計的遊戲圖形庫。最初的Allegro執行在 DOS環境下,而目前可執行在Linux FrameBuffer控制檯、Linux SVGALib、X Window等系統上。Allegro提供了一些豐富的圖形功能,包括矩形填充和樣條曲線生成等等,而且具有較好的三維圖形顯示能力。由於Allegro的許多關鍵程式碼是採用彙編編寫的,所以該函式庫具有執行速度快、資源佔用少的特點。然而,Allegro也存在如下缺點: 1)對執行緒的支援較差。Allegro的許多函式是非執行緒安全的,不能同時在兩個以上的執行緒中使用。 2)對硬體加速能力的支援不足,在設計上沒有為硬體加速提供介面。 有關 Allegro 的進一步資訊,可參閱。 2.4 Mesa3D Mesa3D是一個相容OpenGL規範的開放原始碼函式庫,是目前Linux上提供專業三維圖形支援的惟一選擇。Mesa3D同時也是一個跨平臺的函式庫,能夠執行在X Window、X Window with DGA、BeOS、Linux SVGALib 等平臺上。 有關 Mesa3D 的進一步資訊,可參閱 。 2.5 DirectFB DirectFB是專注於Linux FrameBuffer硬體加速的一個圖形庫,並試圖建立一個相容GTK的嵌入式GUI系統。它以可裝載函式庫的形式提供對加速 FrameBuffer驅動程式的支援。目前,該函式庫正在開發之中(最新版本 0.9.97),詳情可見 。三、面向嵌入式Linux系統的圖形使用者介面 3.1 MicoroWindows/NanoX MicroWindows()是一個開放原始碼的專案,目前由美國Century Software公司主持開發。該專案的開發一度非常活躍,國內也有人蔘與了其中的開發,並編寫了GB2312等字符集的支援。但在 Qt/Embedded釋出以來,該專案變得不太活躍,並長時間停留在0.89Pre7版本。可以說,以開放原始碼形勢發展的MicroWindows專案,已基本停滯。 MicroWindows是一個典型的基於客戶/伺服器體系結構的GUI系統,基本分為三層。最底層是面向圖形輸出和鍵盤、滑鼠或觸控式螢幕的驅動程式;中間層提供底層硬體的抽象介面,並進行視窗管理;最高層分別提供兼容於X Window和 Windows CE(Win32 子集)的API。 該專案的主要特色在於提供了類似X的客戶/伺服器體系結構,並提供了相對完善的圖形功能,包括一些高階的功能,比如Alpha混合,三維支援,TrueType 字型支援等。但需要注意的是,MicroWindows的圖形引擎存在許多問題,可以歸納如下: 1)無任何硬體加速能力。 2)圖形引擎中存在許多低效演算法,同時未經任何優化。比如在直線或者圓弧繪圖函式中,存在低效的逐點判斷剪下的問題。 3)程式碼質量較差。由於該專案缺少一個強有力的核心程式碼維護人員,因此程式碼質量參差不齊,影響整體系統穩定性。這也是MicroWindows長時間停留在 0.89Pre7 版本上的原因。 MicroWindows 採用MPL條款釋出(該條款基本類似 LGPL 條款)。 3.2 OpenGUI OpenGUI()在Linux系統上存在已經很長時間了。最初的名字叫FastGL,只支援256色的線性視訊記憶體模式,但目前也支援其他顯示模式,並且支援多種作業系統平臺,比如 MS-DOS、QNX 和Linux等等,不過目前只支援x86硬體平臺。OpenGUI也分為三層。最低層是由彙編編寫的快速圖形引擎;中間層提供了圖形繪製API,包括線條、矩形、圓弧等,並且兼容於 Borland的BGI API。第三層用C++編寫,提供了完整的GUI物件集。 OpenGUI採用LGPL條款釋出。OpenGUI比較適合於基於x86平臺的實時系統,可移植性稍差,目前的發展也基本停滯。 3.3 Qt/Embedded Qt/Embedded是著名的Qt庫開發商TrollTech()釋出的面向嵌入式系統的Qt版本。因為Qt是KDE等專案使用的GUI支援庫,所以有許多基於Qt 的X Window程式可以非常方便地移植到Qt/Embedded版本上。因此,自從Qt/Embedded以GPL條款形勢釋出以來,就有大量的嵌入式Linux開發商轉到了Qt/Embedded系統上。比如韓國的Miz 公司,臺灣省的某些嵌入式Linux應用開發商等等。 不過,在筆者看來,Qt/Embedded還有一些問題值得開發者注意: 1)目前,該系統採用兩種條款釋出,其中包括GPL條款。對函式庫使用GPL條款,意味著其上的應用需要遵循GPL條款。當然了,如果要開發商業程式,TrollTech也允許你採用另外一個授權條款,這時,就必須向TrollTech交納授權費用了。 2)Qt/Embedded是一個C++函式庫,儘管Qt/Embedded聲稱可以裁剪到最少 630K,但這時的Qt/Embedded庫已經基本上失去了使用價值。低的程式效率、大的資源消耗也對執行Qt/Embedded的硬體提出了更高的要求。 3)Qt/Embedded庫目前主要針對手持式資訊終端,因為對硬體加速支援的匱乏,很難應用到對圖形速度、功能和效率要求較高的嵌入式系統當中,比如機頂盒、遊戲終端等等。 4)Qt/Embedded提供的控制元件集風格沿用了PC風格,並不太適合許多手持裝置的操作要求。 5)Qt/Embedded的結構過於複雜,很難進行底層的擴充、定製和移植,尤其是那個用來實現signal/slot機制的著名的moc檔案。 因為上述這些原因,目前所見到的Qt/Embedded 的執行環境,幾乎是清一色基於StrongARM的iPAQ。 注:目前,Qt/Embedded已經增加了對DirectFB驅動的支援,因此具有了圖形加速能力,其效能也大大地得到提高。
3.4 MiniGUI MiniGUI()是由許多自由軟體開發人員支援的一個自由軟體專案(遵循 LGPL 條款釋出),其目標是為基於Linux 的實時嵌入式系統提供一個輕量級的圖形使用者介面支援系統。該專案自 1998 年底開始到現在,已歷經3年多的開發過程。到目前為止,已經非常成熟和穩定。目前,已經正式釋出了穩定版本 1.0.9,並且開始了新版本系列的開發,即 MiniGUI Version 1.1.x,該系列的正式版也即將釋出。 在MiniGUI幾年的發展過程中,有許多值得一提的技術創新點,正是由於這些技術上的創新,才使得 MiniGUI 更加適合實時嵌入式系統;而且 MiniGUI 的靈活性非常好,可以應用在包括手持裝置、機頂盒、遊戲終端等等在內的各種高階或者低端的嵌入式系統當中。這些技術創新包括: 1)圖形抽象層。圖形抽象層對頂層 API 基本沒有影響,但大大方便了 MiniGUI 應用程式的移植、除錯等工作。目前包含三個圖形引擎,SVGALib、LibGGI 以及直接基於 Linux FrameBuffer 的 Native Engine,利用 LibGGI 時,可在 X Window 上執行 MiniGUI 應用程式,並可非常方便地進行除錯。與圖形抽象層相關的還有輸入事件的抽象層。MiniGUI 現在已經被證明能夠在基於 ARM、MIPS、StrongARM 以及 PowerPC 等的嵌入式系統上流暢執行。 2)多字型和多字符集支援。這部分通過裝置上下文(DC)的邏輯字型(LOGFONT)實現,不管是字型型別還是字符集,都可以非常方便地進行擴充。應用程式在啟動時,可切換系統字符集,比如 GB、BIG5、EUCKR、UJIS。利用 DrawText 等函式時,可通過指定字型而獲得其他字符集支援。對於一個視窗來說,同時顯示不同語種的文字是可能的。MiniGUI 的這種字符集支援不同於傳統通過 UNICODE 實現的多字符集支援,這種實現更加適合於嵌入式系統。3)兩個不同架構的版本。最初的 MiniGUI 執行在 PThread 庫之上,這個版本適合於功能單一的嵌入式系統,但存在系統健壯性不夠的缺點。在 0.9.98 版本中,我們引入了 MiniGUI-Lite 版本,這個版本在提高系統健壯性的同時,通過一系列創新途徑,避免了傳統 C/S 結構的弱點,為功能複雜的嵌入式系統提供了一個高效、穩定的 GUI 系統。 在 MiniGUI 1.1.0 版本的開發中,我們參照 SDL 和 Allegro 的圖形部分,重新設計了圖形抽象層,並增強了圖形功能,同時增強了 MiniGUI-Lite 版本的某些特性。這些特性包括: 1)MiniGUI-Lite 支援層的概念。同一層可容納多個能夠同時顯示的客戶程式,並平鋪在螢幕上顯示。 2)新的 GAL 能夠支援硬體加速能力,並能夠充分使用顯示記憶體;新 GAL 之上的新 GDI 介面得到進一步增強。新的 GDI 介面可以支援 Alpha 混和、透明位塊傳輸、光柵操作、YUV覆蓋、Gamma 校正,以及高階圖形功能(橢圓、多邊形、樣條曲線)等等。 MiniGUI 新版本在圖形方面的增強和提高,將大大擴充套件它的應用領域,希望能夠對嵌入式 Linux 上的多媒體應用、遊戲開發提供支援。 縱觀嵌入式 Linux 系統上的各種圖形系統方案,我們發現,許多圖形系統(如 Qt/Embedded 和 MicoroWindows),只注重手持裝置上的需求,卻不太注重其他應用領域的需求,而其他許多需要圖形支援的嵌入式 Linux 系統卻需要許多獨特的、高階的圖形功能,而不僅僅是圖形使用者介面。為此,在接下來的開發中,我們還將在如下領域繼續開發 MiniGUI: 1)提供執行在 MiniGUI上的 JAVA 虛擬機器 AWT 元件的實現。 2)提供 MiniGUI 上的OpenGL 實現。 3)提供類QT 控制元件集的C++ 封裝。 3)提供視窗/控制元件風格主題支援。 4)在 MiniGUI-Lite 當中增加對向量字型的支援。
四、Linux/Unix系統圖形介面原理簡單介紹及GTK、QT、GNOME和KDE的關係
最近IT新聞出現較多的就是諾基亞的新版手機作業系統Symbian 3。今天看到在cnbeta上看大家為這個系統爭論不休,其焦點也逐漸轉移到到塞班新系統的核心技術:Qt 。評論區大家脣槍舌戰,不過很多人連基本概念都沒搞明白,今天正好無事可做,稍微整理下X11,GTK,QT,GNOME,KDE的區別與聯絡。
一、在這之前你必須要了解:
1.linux是基於Unix的
2.塞班Symbian、蘋果max os等系統的最底層也是unix
3.linux本身沒有圖形介面,linux現在的圖形介面的實現只是linux下的應用程式
實現的
4.Xwindow、Xfree中的X是協議,不是具體的某個軟體
5.linux圖形介面層次關係:linux本身-->X伺服器<-[通過X協議交談]->視窗管
理器(綜合桌面環境)-->X應用程式
二、linux和windows下介面系統的區別:
圖形介面並不是linux的一部分 ,linux只是一個基於命令列的作業系統,linux和Xfree的關係就相當於當年的DOS和 WINDOWS3.0一樣,windows3.0不是獨立的作業系統,它只是DOS的擴充,是DOS下的應用程式級別的系統,不是獨立的作業系統,同樣 XFree只是linux下的一個應用程式而已.不是系統的一部分,但是X的存在可以方便使用者使用電腦.WINDOWS95及以後的版本就不一樣了,他們 的圖形介面是作業系統的一部分,圖形介面在系統核心中就實現了,沒有了圖形介面windows就不成為windows了,但linux卻不一樣,沒有圖形介面linux還是linux,很多裝linux的WEB伺服器就根本不裝X伺服器。這也WINDOWS和linux的重要區別之一。
三、關於linux兩大圖形介面KDE和Gnome
KDE早於Gnome出現,但是KDE基於的Qt是不遵循GPL開源協議的,Qt是一個跨平臺的C++圖形使用者介面庫 ,它是挪威TrollTech公司的產品(2008年底被NOKIA收購)。 Qt具有優良的跨平臺特性(支援Windows、Linux、各種UNIX、OS390和QNX等)、面向物件機制以及豐富的API,同時也可支援2D/3D渲染和OpenGL API。在當時的同類圖形使用者介面庫產品中,Qt的功能最為強大.但底層的基礎 Qt卻是一個不遵循GPL的商業軟體,這就給KDE上了一道無形的枷鎖並帶來可能的法律風險。一大批自由程式設計師對KDE專案的決定深為不滿,它們認為利用非自由軟體開發違背了GPL的精神。於是這些GNU的狂熱信徒兵分兩路:其中一部分人去製作Harmonny,試圖重寫出一套相容Qt的替代品,這個專案雖然技術上相對簡單,但卻沒有獲得KDE專案的支援;另一路人馬則決定重新開發一套名為“GNOME(GNU Network Object Environment)”的圖形環境來替代KDE。
GNOME選擇完全遵循GPL的GTK圖形介面庫為基礎,因此我們也一般將GNOME和KDE兩大陣營稱為GNOME/GTK和 KDE/Qt。與Qt基於C++語言不同,GTK採用較傳統的C語言 ,雖然C語言不支援面向物件設計,看起來比較落後,但當時熟悉C語言的開發者遠遠多於熟悉C++的開發者。加之GNOME/GTK完全遵循GPL版權公約,吸引了更多的自由程式設計師參與。
四、linux/unix基於X window的圖形顯示處理原理
X Window從邏輯上分為三層:最底層的X Server(X伺服器)主要處理輸入/輸出資訊並維護相關資源,它接受來自鍵盤、滑鼠的操作並將它交給X Client(X客戶端)作出反饋,而由X Client傳來的輸出資訊也由它來負責輸出;最外層的X Client則提供一個完整的GUI介面,負責與使用者的直接互動(KDE、Gnome都是一個X Client),而銜接X Server與X Client的就是“X Protocol(X通訊協議)”、它的任務是充當這兩者的溝通管道。儘管UNIX廠商採用相同的X Window,但終端的X Client並不相同。
五、Qt、GTK 和KDE、GNOME的關係
簡單來說:為了方便開發人員編寫X clients,就有了Xlib來封裝X協議;Xlib還不夠方便,於是就有了qt和gtk,它們提供了很多視窗控制元件(widgets)。為了方便使用者 ,就出現了gnome和kde等桌面管理系統。一般來說,linux使用者看到的介面就是其中之一了。gnome用的是gtk庫,kde用的是qt庫。