FLTK簡介
FLTK,如同其名字所表達的:The Fast Light Tool
Kit,一個輕量級的GUI開發庫。但這輕量級并不代表功能的羸弱,相反,FLTK在具有基本的GUI功能之外,還擁有一些特殊的功能,比如跨平臺、內置
OpenGL功能、速度更快、尺寸更小、協議寬松等。當然,缺點也是有的,比如對于復雜的界面構件支持不夠,資源支持的不足等。但一個工具如果使用的好,
取其長而去其短,自然可以飛花摘葉皆可傷人;P
我選擇FLTK 的過程還是比較曲折的,當初做ARM下的GUI開發,選擇的GUI庫是MiniGUI,一個國內開發的界面庫。當時還支持類unix平臺,對 Windows的支持尚在開發中。由于需要尋找一些問題的解答,所以經常在其論壇上搜索,從而知道了還有microwindow、nano、 qtembedded等嵌入型GUI開發庫,但當時沒有太過注意。后來又開始轉向WINCE平臺的開發,這一擱就是2年。再后來終于要做跨平臺的開發,對 具有跨平臺的GUI開發庫開始注意起來。
一開始的選擇是wxWidgets,但是研究了一段時間后發現不好解決的問題越來越多,終于 放棄。最頭疼的就是C++類的事件傳遞,wxWidgets內部使用的是一個類似MFC的方法,所有傳遞事件的類全部要從一個根類繼承,這樣就導致創建的 類和wxWidgets綁定過甚,復用性大大降低,同時由于wxWidgets的目標不僅僅是GUI,造成其包含功能過多,其內部結構非常復雜,雖然是 OpenSource,但要若要修改其代碼還是很困難的。綜上所述,wxWidgets并不符合我的要求,從而被排除在外。
之后研究的QT,老牌的跨平臺GUI開發庫,工具很多,開發也很人性化,qtdesign很像Delphi的界面開發方式,代碼帶有強烈的linux風格,但是看看附帶的庫文件又實在讓人有些泄氣,尺寸大,發布麻煩。所以在試用了一段時間后還是放棄了。
在此期間,其實也看到過一些對FLTK的介紹,但大多數對其評價不高,也就沒有注意。直到有一次偶然心血來潮,上http: //www.fltk.org看了一下,發現FLTK 似乎正對我的胃口,這才開始對其進行了深入的研究。經過一段時間的實際開發,個人覺得,對于跨平臺和代碼簡潔而言,FLTK是再適合不過了。
FLTK的底層只提供一套完整的畫點、畫線功能,另外附帶了字體的顯示功能,但FLTK對字體的支持還很粗糙,尤其對于非英文字符集而言,后面我會詳細 說明。在基本的點、線功能基礎上,FLTK完全自己實現了一套界面,比如Button、Label、Edit、Tab等,全部都是由基本的點線畫出??吹? 這,可能你會覺得這實在是屬于自己造輪子,吃力不討好。誠然,如果你只針對一種平臺開發,這樣的做法不能帶來多少好處,還造成學習時間的拉長。但若要針對 多個平臺開發,這樣做的好處就很明顯了。首先是移植容易,只要針對目標平臺實現基本的點線功能就可以實現代碼的移植,這可能是所有跨平臺GUI庫中最方便 最直接的方案,目前FTLK支持MacOS、Windows、Linux(x-window)等平臺,針對WinCE(主要是unicode的問題)和 plam 的開發正在進行中。其次是保持了界面的一致性,雖然QT、GTK等開發庫也具有這種功能,但是他們都需要一套基本庫的支持,無法做到系統尺寸的優化,而對 于FLTK而言,這卻恰恰是他的優點和長項。最后是代碼層次清楚、結構簡單,由于大部分的工作就是基于底層的點線功能進行自繪,所有很多代碼都是簡潔明 了,很少費話。
底層之上是一套以Fl_開頭的類,代表了各種GUI構件,比如Fl_Window、Fl_Button、 Fl_Input等,使用起來很是容易。同時由于上面所說的,所有的界面構件都是畫出來的,因此在熟悉了這種方式后,生成自己的構件也是很容易的,反正是 畫界面嘛,既然別人能做到,你也能做到,實在不行可以查閱源代碼進行學習。這些界面類的共同特點是輕量型、都擁有一個draw(),只要在draw()里 實現自己的繪畫動作即可。
說到界面就不能不說其事件實現方式,對于FLTK而言,使用的是最直接的方法:while(1){}。這也 是很多人批評FLTK原始的一個原因。但仔細想想,其實這是最直接的辦法,不管是哪種平臺,最終的事件方案不外乎是死循環和中斷,中斷的確具有很多好處, 但只要while(1)能完成這部分的功能,那又有什么關系呢。每個界面類都有一個handle(int event),只要繼承這個成員函數,就可以在其中處理自己的事務。是不是很簡單?同時由于這樣的事件方式,造成FLTK的刷新速度很快,事件反應迅速, 也算是個附帶優點了。現在大多數的開發庫都是采用OO方式的事件處理方式,但FLTK卻采用了最原始的函數指針方式,也算是一個異類,這可能和FLTK的 unix背景有關,無論如何,這種方式還是需要一定的適應時間的,而且這種方式的優缺點也是屬于各花入各眼了,不過我本人還是很喜歡這種方式的,誰叫我比 較原始呢#-_-
FLTK產生于NeXT環境,發展于X-window環境,所以對圖形加速的支持必然是選擇OpenGL。FLTK 使用Fl_Gl_Window這個類將OpenGL的基本功能囊括其中,只要在Fl_Gl_Window的draw()里glbegin/glend即 可,基本的設置工作FLTK全都做好了,對于我現在的系統要求簡直是最適合不過了。
FLTK基于LGPL,對使用者的要求非常寬松: Contrary to popular belief, it can be used in commercial software - even Bill Gates could use it! 所以開發者不需要擔心其項目的隱形問題。但是如果對FLTK進行了卓有成效的修正最好還是能回饋給開發組,所謂我為人人,人人為我嘛。
說了一堆的好話,現在開始談談FLTK的缺點。首先一條就是對非英文字體特別是中文的支持比較差,甚至是非常差。在Windows平臺下還好一點,因為 在 Windows平臺下使用的是TextOut函數輸出字符串,但是在X-Window環境下就完蛋了,無法正確顯示中文,也不能調用輸入法進行輸入。從這 點來說,FLTK還是只適合一些封閉軟件的開發,對于通用軟件而言FLTK并非是一個好的選擇。但只能在Windows平臺下開發中文軟件也不是個辦法, 要解決中文的顯示問題也不難,目前FTLK的穩定版是1.1.7,開發版是2.0,有人針對1.xx版本修改了一個unicode版本,可以很平滑的支持 漢字的顯示,但很遺憾,我沒有編譯成功過,如果誰編譯成功了可以給我來個信。2.0已經對非英文的支持進行了專門的開發,但目前還沒有release,在 不久的將來應該可以完整的解決這個問題。目前,要么等待,要么就像我這樣,用點陣字庫瞞天過海。具體方法因為還不夠成熟,就不公布了。
無論如何,FLTK的目標還是針對嵌入式和封閉軟件的開發,所以復雜的界面并非其長項,如果想做出花哨復雜的界面,還是用其他GUI庫比較好,FLTK并不適合。
綜上所述,FLTK的優點和缺點都是非常的突出,如何取舍還是自己決定吧。
2006-04-16 22:02
我選擇FLTK 的過程還是比較曲折的,當初做ARM下的GUI開發,選擇的GUI庫是MiniGUI,一個國內開發的界面庫。當時還支持類unix平臺,對 Windows的支持尚在開發中。由于需要尋找一些問題的解答,所以經常在其論壇上搜索,從而知道了還有microwindow、nano、 qtembedded等嵌入型GUI開發庫,但當時沒有太過注意。后來又開始轉向WINCE平臺的開發,這一擱就是2年。再后來終于要做跨平臺的開發,對 具有跨平臺的GUI開發庫開始注意起來。
一開始的選擇是wxWidgets,但是研究了一段時間后發現不好解決的問題越來越多,終于 放棄。最頭疼的就是C++類的事件傳遞,wxWidgets內部使用的是一個類似MFC的方法,所有傳遞事件的類全部要從一個根類繼承,這樣就導致創建的 類和wxWidgets綁定過甚,復用性大大降低,同時由于wxWidgets的目標不僅僅是GUI,造成其包含功能過多,其內部結構非常復雜,雖然是 OpenSource,但要若要修改其代碼還是很困難的。綜上所述,wxWidgets并不符合我的要求,從而被排除在外。
之后研究的QT,老牌的跨平臺GUI開發庫,工具很多,開發也很人性化,qtdesign很像Delphi的界面開發方式,代碼帶有強烈的linux風格,但是看看附帶的庫文件又實在讓人有些泄氣,尺寸大,發布麻煩。所以在試用了一段時間后還是放棄了。
在此期間,其實也看到過一些對FLTK的介紹,但大多數對其評價不高,也就沒有注意。直到有一次偶然心血來潮,上http: //www.fltk.org看了一下,發現FLTK 似乎正對我的胃口,這才開始對其進行了深入的研究。經過一段時間的實際開發,個人覺得,對于跨平臺和代碼簡潔而言,FLTK是再適合不過了。
FLTK的底層只提供一套完整的畫點、畫線功能,另外附帶了字體的顯示功能,但FLTK對字體的支持還很粗糙,尤其對于非英文字符集而言,后面我會詳細 說明。在基本的點、線功能基礎上,FLTK完全自己實現了一套界面,比如Button、Label、Edit、Tab等,全部都是由基本的點線畫出??吹? 這,可能你會覺得這實在是屬于自己造輪子,吃力不討好。誠然,如果你只針對一種平臺開發,這樣的做法不能帶來多少好處,還造成學習時間的拉長。但若要針對 多個平臺開發,這樣做的好處就很明顯了。首先是移植容易,只要針對目標平臺實現基本的點線功能就可以實現代碼的移植,這可能是所有跨平臺GUI庫中最方便 最直接的方案,目前FTLK支持MacOS、Windows、Linux(x-window)等平臺,針對WinCE(主要是unicode的問題)和 plam 的開發正在進行中。其次是保持了界面的一致性,雖然QT、GTK等開發庫也具有這種功能,但是他們都需要一套基本庫的支持,無法做到系統尺寸的優化,而對 于FLTK而言,這卻恰恰是他的優點和長項。最后是代碼層次清楚、結構簡單,由于大部分的工作就是基于底層的點線功能進行自繪,所有很多代碼都是簡潔明 了,很少費話。
底層之上是一套以Fl_開頭的類,代表了各種GUI構件,比如Fl_Window、Fl_Button、 Fl_Input等,使用起來很是容易。同時由于上面所說的,所有的界面構件都是畫出來的,因此在熟悉了這種方式后,生成自己的構件也是很容易的,反正是 畫界面嘛,既然別人能做到,你也能做到,實在不行可以查閱源代碼進行學習。這些界面類的共同特點是輕量型、都擁有一個draw(),只要在draw()里 實現自己的繪畫動作即可。
說到界面就不能不說其事件實現方式,對于FLTK而言,使用的是最直接的方法:while(1){}。這也 是很多人批評FLTK原始的一個原因。但仔細想想,其實這是最直接的辦法,不管是哪種平臺,最終的事件方案不外乎是死循環和中斷,中斷的確具有很多好處, 但只要while(1)能完成這部分的功能,那又有什么關系呢。每個界面類都有一個handle(int event),只要繼承這個成員函數,就可以在其中處理自己的事務。是不是很簡單?同時由于這樣的事件方式,造成FLTK的刷新速度很快,事件反應迅速, 也算是個附帶優點了。現在大多數的開發庫都是采用OO方式的事件處理方式,但FLTK卻采用了最原始的函數指針方式,也算是一個異類,這可能和FLTK的 unix背景有關,無論如何,這種方式還是需要一定的適應時間的,而且這種方式的優缺點也是屬于各花入各眼了,不過我本人還是很喜歡這種方式的,誰叫我比 較原始呢#-_-
FLTK產生于NeXT環境,發展于X-window環境,所以對圖形加速的支持必然是選擇OpenGL。FLTK 使用Fl_Gl_Window這個類將OpenGL的基本功能囊括其中,只要在Fl_Gl_Window的draw()里glbegin/glend即 可,基本的設置工作FLTK全都做好了,對于我現在的系統要求簡直是最適合不過了。
FLTK基于LGPL,對使用者的要求非常寬松: Contrary to popular belief, it can be used in commercial software - even Bill Gates could use it! 所以開發者不需要擔心其項目的隱形問題。但是如果對FLTK進行了卓有成效的修正最好還是能回饋給開發組,所謂我為人人,人人為我嘛。
說了一堆的好話,現在開始談談FLTK的缺點。首先一條就是對非英文字體特別是中文的支持比較差,甚至是非常差。在Windows平臺下還好一點,因為 在 Windows平臺下使用的是TextOut函數輸出字符串,但是在X-Window環境下就完蛋了,無法正確顯示中文,也不能調用輸入法進行輸入。從這 點來說,FLTK還是只適合一些封閉軟件的開發,對于通用軟件而言FLTK并非是一個好的選擇。但只能在Windows平臺下開發中文軟件也不是個辦法, 要解決中文的顯示問題也不難,目前FTLK的穩定版是1.1.7,開發版是2.0,有人針對1.xx版本修改了一個unicode版本,可以很平滑的支持 漢字的顯示,但很遺憾,我沒有編譯成功過,如果誰編譯成功了可以給我來個信。2.0已經對非英文的支持進行了專門的開發,但目前還沒有release,在 不久的將來應該可以完整的解決這個問題。目前,要么等待,要么就像我這樣,用點陣字庫瞞天過海。具體方法因為還不夠成熟,就不公布了。
無論如何,FLTK的目標還是針對嵌入式和封閉軟件的開發,所以復雜的界面并非其長項,如果想做出花哨復雜的界面,還是用其他GUI庫比較好,FLTK并不適合。
綜上所述,FLTK的優點和缺點都是非常的突出,如何取舍還是自己決定吧。
2006-04-16 22:02
posted on 2006-04-16 22:11 cyantree 閱讀(20550) 評論(20) 編輯 收藏 引用