關於Qt
一提起GUI編程，很多人馬上會想起VB、VC++之類的，至多也只會想到Delphi或C++ Builder。這並非好事，證明了人們只會使用IDE進行編程，似乎一離開了IDE，就馬上變得束手無策，或者認爲只有編命令行程序的份了。
事實並非如此，現在我所介紹的東西名叫Qt。Qt是什麼?它不是一個集成開發環境，而只是一個完整的GUI類庫。就像是VC++中的MFC，或Delphi，C++ Builder 裏面的VCL。不過，VC++與MFC的耦合度太高了，脫離了VC++，編寫MFC程序是一件極度困難的事情。
Qt就只是一套類庫，基於成熟的C++語言，用面向對象的思想組織。它支持多平臺，有"一次編寫，到處編譯"的特點，編譯出來的程序可以運行於Win32，Linux，Solaris 及Mac OS X之下，甚至是嵌入式系統。你可以用你最喜歡的編輯器來編寫代碼，再用gcc或其它編譯器編譯程序。另外，你可以用make和cvs來管理代碼。假如你依舊中情於IDE，那也不要緊。在linux 下可選的IDE不少，如KDevelop。而我就更喜歡最近很流行的Eclipse 來管理工程。其實，Eclipse也只是在後臺調用make 和qmake之類的程序而已。
我一向認爲，Borland的VCL是最優秀的GUI Framework，因爲Delphi給我留下的印象太深了。如今，Qt在我心目的位置日漸提升。Qt是開源的，但卻由一間技術先進的公司進行維護，代碼的質量有保證。Qt對平臺上的函數有完善的封裝。無論是圖形界面的生成，還是文件輸入輸出的管理，還是數據庫，TCP/IP網絡的應用，甚至是各種容器和算法的使用，都可以調用Qt類庫完成，而無需調用平臺特有的函數。另外，Qt有一套完整的文檔，包括一個簡單的教程，一份介紹特性的White paper，以及整個類庫的詳細說明。雖說其規模比不上龐大的MSDN，但對於Qt程序員，足矣。
作爲一個GUI類庫，佈局能力是很重要的。你看看VB，雖然我們只需要用鼠標拽幾下就可以在窗口中佈置幾個控件，但這種佈局有其侷限性--因爲這是種絕對位置佈局。所以，當窗口被用戶放大或縮小後，裏面的控件依舊不會調整位置和大小。這時，你就得進行額外的處理，編寫一大堆計算加加減減的代碼，麻煩得很。這就是"Visual "啊。Delphi的處理方法比較特別，程序員可以設置各個控件的上下左右放大策略，也可以將控件放到各個Panel 裏面以進行管理。
Qt有自己的佈局機制。雖然不能像VB和Delphi 那樣可以用鼠標佈局，而要用代碼佈局，但效果決不會差。Qt有幾個管理佈局的類: QHBoxLayout 可將其管理的部件組織到一個從左到右的水平行上，QVBoxLayout可將其管理的部件組織到一個從上到下的垂直列上，QGridLayout可將其管理的部件組織到一個m*n的網格單元中，部件可以佔用一個網格，也可以佔用多個網格。此外，我們還可以設置各種策略，告訴Qt，當窗口大小改變時，裏面的子部件應該如何隨之變化。可以是隨比例放大，也可以不變，也可以是其它行爲。當然，純粹用代碼生成界面的話，我們就要注意將界面與業務的代碼分離，以保證我們的程序易於維護，代碼便於複用。當然，沒有人會阻止你使用鼠標拖放來佈局，Qt爲我們提供了一個名叫Qt Designer的軟件，用法與VB、Delphi 類似，可以嘗試一下。
若從編程思想上來研究Qt，我認爲它的設計還是很優良的，思路十分清晰，組織得很合理。不妨作一個比較。MFC是有名難學的。其原因並非廣大程序員水平不高，而是其設計的確糟糕。雖MFC美名爲"Object based framework "，但其中很多設計是不符合面向對象編程思想的。例如，裏面用到了大量的宏來完成各種工作，包括消息映射，彷彿回到了C語言時代。另外，只要離開了VC+ +的MFC Wizard ，要寫個程序極爲麻煩和痛苦。而且MFC對Windows API封裝並不徹底，到處可以找到底層API的痕跡，例如定義消息的宏。總而言之，就是一個亂字。Qt則大不相同，一切整整有條。大部分類都繼承自 QBoject，一般來說，窗口部件是 QWidget 或其子類的實例。而有框架的類就繼承自QFrame。Qt中有許多類，不是用來被直接使用的，而是用來供程序員子類化來生成新組件。例如QButton，一般我們不會直接使用它，而是使用其子類QPushButton。一個窗口部件可包含任意數量的子部件。子部件在父部件的區域內顯示。沒有父部件的部件是頂級部件（比如一個窗口），通常在桌面環境的任務欄上有它們的入口。QT不在窗口部件上施加任何限制。任何部件都可以是頂級部件；任何部件都可以是其他部件的子部件。通過自動或手動（如果你喜歡）地使用佈局管理器可以設定子部件在父部件區域中的位置。如果父部件被停用，隱藏或刪除，同樣的動作會遞歸地應用於它的所有子部件。
目前，Linux下面有近一半的GUI程序是基於Qt的。例如被廣泛使用的桌面環境(Desktop Environment)KDE就是用Qt實現的。很多出色的GUI程序，都是基於Qt，或者比Qt更高一層的KDE框架。例如音樂播放器Amarok，刻錄軟件K3B，Office套件KOffice等等。Linux下面另一個比較流行的Framework是Gtk，但感覺Gtk編寫出來的程序在界面上過於簡潔，靈活性不是很強，給人一種不成熟的感覺。但是，Qt的許可規定：Qt的開源版本不允許用來開發商業軟件，，否則要付費。因此，很多商業軟件，或說商業軟件公司，都使用Gtk來開發自己的軟件，以避免法律糾紛。例如NVidia的驅動配置程序，Realplayer for linux，Adobe Reader，VMware，其GUI界面無一不是基於Gtk的。
現在，很多人還是隻知道用VB，VC等工具開發軟件，爲何不嘗試一下使用Qt？基本上很多人都在使用盜版的開發工具，爲何不嘗試有合法授權的Qt開源版？我不敢說Qt做得盡善盡美。只是許多同學經常問我，或向我提及VB6，VC++6有何好處有何優點。我覺得我們的眼光應該放開一點，衝出MS的技術包圍，多接觸一些新鮮的東西。遺憾的是，目前關於Qt3的編程書籍不多，一本是Linux開發大師倪繼利寫的，比較高深，而且着重點是嵌入式Linxu軟件開發。另一本是官方推薦的書籍，英文名叫C++ GUI Programming with Qt 3，中文名叫《C++ GUI QT3編程》，不過此書感覺很一般，不大好看。反正看Qt自帶的文檔學到的東西更多，書籍就成爲了次要的參考資料。
總而言之，Qt值得你的嘗試。
======================================================
#after ./configure
#following content displayed.
Qt is now configured for building. Just run 'make'.
Once everything is built, you must run 'make install'.
Qt will be installed into /usr/local/Trolltech/Qt-4.3.3
To reconfigure, run 'make confclean' and 'configure'.
一提起GUI編程，很多人馬上會想起VB、VC++之類的，至多也只會想到Delphi或C++ Builder。這並非好事，證明了人們只會使用IDE進行編程，似乎一離開了IDE，就馬上變得束手無策，或者認爲只有編命令行程序的份了。
事實並非如此，現在我所介紹的東西名叫Qt。Qt是什麼?它不是一個集成開發環境，而只是一個完整的GUI類庫。就像是VC++中的MFC，或Delphi，C++ Builder 裏面的VCL。不過，VC++與MFC的耦合度太高了，脫離了VC++，編寫MFC程序是一件極度困難的事情。
Qt就只是一套類庫，基於成熟的C++語言，用面向對象的思想組織。它支持多平臺，有"一次編寫，到處編譯"的特點，編譯出來的程序可以運行於Win32，Linux，Solaris 及Mac OS X之下，甚至是嵌入式系統。你可以用你最喜歡的編輯器來編寫代碼，再用gcc或其它編譯器編譯程序。另外，你可以用make和cvs來管理代碼。假如你依舊中情於IDE，那也不要緊。在linux 下可選的IDE不少，如KDevelop。而我就更喜歡最近很流行的Eclipse 來管理工程。其實，Eclipse也只是在後臺調用make 和qmake之類的程序而已。
我一向認爲，Borland的VCL是最優秀的GUI Framework，因爲Delphi給我留下的印象太深了。如今，Qt在我心目的位置日漸提升。Qt是開源的，但卻由一間技術先進的公司進行維護，代碼的質量有保證。Qt對平臺上的函數有完善的封裝。無論是圖形界面的生成，還是文件輸入輸出的管理，還是數據庫，TCP/IP網絡的應用，甚至是各種容器和算法的使用，都可以調用Qt類庫完成，而無需調用平臺特有的函數。另外，Qt有一套完整的文檔，包括一個簡單的教程，一份介紹特性的White paper，以及整個類庫的詳細說明。雖說其規模比不上龐大的MSDN，但對於Qt程序員，足矣。
作爲一個GUI類庫，佈局能力是很重要的。你看看VB，雖然我們只需要用鼠標拽幾下就可以在窗口中佈置幾個控件，但這種佈局有其侷限性--因爲這是種絕對位置佈局。所以，當窗口被用戶放大或縮小後，裏面的控件依舊不會調整位置和大小。這時，你就得進行額外的處理，編寫一大堆計算加加減減的代碼，麻煩得很。這就是"Visual "啊。Delphi的處理方法比較特別，程序員可以設置各個控件的上下左右放大策略，也可以將控件放到各個Panel 裏面以進行管理。
Qt有自己的佈局機制。雖然不能像VB和Delphi 那樣可以用鼠標佈局，而要用代碼佈局，但效果決不會差。Qt有幾個管理佈局的類: QHBoxLayout 可將其管理的部件組織到一個從左到右的水平行上，QVBoxLayout可將其管理的部件組織到一個從上到下的垂直列上，QGridLayout可將其管理的部件組織到一個m*n的網格單元中，部件可以佔用一個網格，也可以佔用多個網格。此外，我們還可以設置各種策略，告訴Qt，當窗口大小改變時，裏面的子部件應該如何隨之變化。可以是隨比例放大，也可以不變，也可以是其它行爲。當然，純粹用代碼生成界面的話，我們就要注意將界面與業務的代碼分離，以保證我們的程序易於維護，代碼便於複用。當然，沒有人會阻止你使用鼠標拖放來佈局，Qt爲我們提供了一個名叫Qt Designer的軟件，用法與VB、Delphi 類似，可以嘗試一下。
若從編程思想上來研究Qt，我認爲它的設計還是很優良的，思路十分清晰，組織得很合理。不妨作一個比較。MFC是有名難學的。其原因並非廣大程序員水平不高，而是其設計的確糟糕。雖MFC美名爲"Object based framework "，但其中很多設計是不符合面向對象編程思想的。例如，裏面用到了大量的宏來完成各種工作，包括消息映射，彷彿回到了C語言時代。另外，只要離開了VC+ +的MFC Wizard ，要寫個程序極爲麻煩和痛苦。而且MFC對Windows API封裝並不徹底，到處可以找到底層API的痕跡，例如定義消息的宏。總而言之，就是一個亂字。Qt則大不相同，一切整整有條。大部分類都繼承自 QBoject，一般來說，窗口部件是 QWidget 或其子類的實例。而有框架的類就繼承自QFrame。Qt中有許多類，不是用來被直接使用的，而是用來供程序員子類化來生成新組件。例如QButton，一般我們不會直接使用它，而是使用其子類QPushButton。一個窗口部件可包含任意數量的子部件。子部件在父部件的區域內顯示。沒有父部件的部件是頂級部件（比如一個窗口），通常在桌面環境的任務欄上有它們的入口。QT不在窗口部件上施加任何限制。任何部件都可以是頂級部件；任何部件都可以是其他部件的子部件。通過自動或手動（如果你喜歡）地使用佈局管理器可以設定子部件在父部件區域中的位置。如果父部件被停用，隱藏或刪除，同樣的動作會遞歸地應用於它的所有子部件。
目前，Linux下面有近一半的GUI程序是基於Qt的。例如被廣泛使用的桌面環境(Desktop Environment)KDE就是用Qt實現的。很多出色的GUI程序，都是基於Qt，或者比Qt更高一層的KDE框架。例如音樂播放器Amarok，刻錄軟件K3B，Office套件KOffice等等。Linux下面另一個比較流行的Framework是Gtk，但感覺Gtk編寫出來的程序在界面上過於簡潔，靈活性不是很強，給人一種不成熟的感覺。但是，Qt的許可規定：Qt的開源版本不允許用來開發商業軟件，，否則要付費。因此，很多商業軟件，或說商業軟件公司，都使用Gtk來開發自己的軟件，以避免法律糾紛。例如NVidia的驅動配置程序，Realplayer for linux，Adobe Reader，VMware，其GUI界面無一不是基於Gtk的。
現在，很多人還是隻知道用VB，VC等工具開發軟件，爲何不嘗試一下使用Qt？基本上很多人都在使用盜版的開發工具，爲何不嘗試有合法授權的Qt開源版？我不敢說Qt做得盡善盡美。只是許多同學經常問我，或向我提及VB6，VC++6有何好處有何優點。我覺得我們的眼光應該放開一點，衝出MS的技術包圍，多接觸一些新鮮的東西。遺憾的是，目前關於Qt3的編程書籍不多，一本是Linux開發大師倪繼利寫的，比較高深，而且着重點是嵌入式Linxu軟件開發。另一本是官方推薦的書籍，英文名叫C++ GUI Programming with Qt 3，中文名叫《C++ GUI QT3編程》，不過此書感覺很一般，不大好看。反正看Qt自帶的文檔學到的東西更多，書籍就成爲了次要的參考資料。
總而言之，Qt值得你的嘗試。
======================================================
#after ./configure
#following content displayed.
Qt is now configured for building. Just run 'make'.
Once everything is built, you must run 'make install'.
Qt will be installed into /usr/local/Trolltech/Qt-4.3.3
To reconfigure, run 'make confclean' and 'configure'.