cyantree's home

     摘要: 基本上，fltk認為所有的操作系統(tǒng)都會提供以下幾種功能：
1.窗口創(chuàng)建和銷毀
2.繪圖(點，直線，曲線，圓...）
3.字體顯示
4.輸入設(shè)備交互(鍵盤、鼠標)

只要有這幾種功能，不需要系統(tǒng)提供全套的控件，也可以自行構(gòu)建出界面。另外系統(tǒng)還會提供一些附加功能，對于豐富界面也很有幫助，但并不是充分必要條件，比如
1.圖片讀寫
2.文件操作
3.打印機
4.輸入法

基于這樣的認知，做為一個GUI庫，fltk需要提供一個模型，把這些元素組合在一起，既要有足夠的彈性又要足夠簡單  閱讀全文

     摘要: 先貼一段fltk的官網(wǎng)介紹：

FLTK (pronounced "fulltick") is a cross-platform C++ GUI toolkit for UNIX?/Linux? (X11), Microsoft? Windows?, and MacOS? X. FLTK provides modern GUI functionality without the bloat and supports 3D graphics via OpenGL? and its built-in GLUT emulation.

FLTK是一套適用于unix/linux、windows和macos的跨平臺c++界面庫，尺寸精簡，具有現(xiàn)代GUI功能，支持OpenGL，內(nèi)置glut

FLTK is designed to be small and modular enough to be statically linked, but works fine as a shared library. FLTK also includes an   閱讀全文

     摘要: 問題描述：
在windows下，當FLTK界面包含中文的時候，打開程序的時候會花費好幾秒的時間才能完整顯示界面

原因：
查了代碼，最后發(fā)現(xiàn)原因在于繪制字符的時候通過GetTextExtentPoint32W這個函數(shù)獲取字符寬度，由于這個函數(shù)本身速度不夠快，所以FLTK使用緩存方式來保存寬度，問題在于緩存的方式不適合中文這種寬字符，當前的緩存方式是每當獲取一個字符寬度時，把這個字符左右共1024個相鄰字符的寬度提前獲取并保存，以后每次獲取字符寬度之前先搜索緩存，如果沒有再通過API實際獲取。

這個做法對于英文沒有問題，因為GetTextExtentPoint32W處理英文的速度很快，而且一次獲取1024個相鄰字符基本就把程序可能會用到的字符全部囊括了，但是當界面出現(xiàn)中文的時候這種做法就出現(xiàn)問題了，中文的字符集是很大的，一次獲取相鄰個1024字符寬度并不能保證囊括了絕大多數(shù)的字符，所以每次界面顯示之前都會花很多時間獲取很多用不到的字符寬度，雖然顯示一次之后的速度很快，但是啟動程序的時候會出現(xiàn)卡頓

所以我做了修正，每當需要  閱讀全文

     摘要: [本教程翻譯自http://www3.telus.net/public/robark/]新手入門 版本: 1.1 目錄更新歷史目標人群知識預(yù)備為何使用FLTK編寫GUI程序?獲取FLTK進入FLTK基礎(chǔ)課程 視頻教程  一個簡單的窗口程序(Simple Window Function)有關(guān)控件Label的陷阱(Widget Label Pitfall)  (新)控件間通訊...  閱讀全文

群號：32425450

歡迎對fltk有興趣的開發(fā)人員加入

==========================

描述：
在windows下創(chuàng)建一個resizable window，最大化的時候會出錯，窗口的最下方實際上并沒有和任務(wù)欄靠在一起，而且如果任務(wù)欄很高，那更是奇怪，窗口會超出任務(wù)欄

原因：
懷疑實現(xiàn)部分并非是由系統(tǒng)處理，而且自己處理了這個事件，沒有去看代碼，暫時存疑

解決：
無。只有找到源代碼的實現(xiàn)部分才知道怎么修改了

不久前fltk終于釋出可以實用的2.0版本，目前的具體版本是2.0.x-r5556，讓我們看看具體的更新和變動

首先是字體 的巨大改進，開始支持utf8，所以在linux下漢字無法顯示和輸入法無法輸入的問題已經(jīng)徹底解決，但同時也帶來一些問題，就是在代碼內(nèi)必須使用 utf8的漢字才能正確顯示在界面上，但是unicode的編輯器又不是那么好找，再說在windows下開發(fā)的話一般都會使用vc，而在vc下輸入 unicode是一件有困難的事情，至少我沒有找到好的插件，所以需要一個解決辦法，那就是里的函數(shù)，幫助文檔里沒 有說的很清楚，但是大體上還是可以猜到意思的

修 改了class Browser，變成了一個tree，在1.0中想顯示一個grid或者listview一直只能自己處理，現(xiàn)在不用了，這個Browser還算可以，提 供了基本的功能，稍微還有一些擴充，如果想再豐富一些就只有自己繼承了，反正fltk的宗旨就是自己動手豐衣足食。

Opengl的功能貌似有一些修正，但是我沒有用到，而且demo中關(guān)于OpenGL的例子還沒有提供，所以目前情況未知

幫助文檔未完善，而且代碼中附帶的幫助無法使用，所以很多時候還是查1.0的幫助以及看源代碼更加有效一些

所 有的頭文件和類名全部去除了FL_，引入了namespace，好處是類看起來更清楚了，壞處是從1.0的代碼升級變得很麻煩。頭文件從<FL/FL_XXXX.H>變成<fltk/xxxx.h>，全部變成了小寫，而且去掉了FL_，同時目錄也變成fltk/了，這些細 節(jié)稍微用一段時間就會習慣，一開始會造成一些問題，雖然在fltk目錄下也保留了一些兼容的頭文件，但是建議還是不要用，因為不全，而且遲早要換的， 何必不一步到位？

對編譯器支持的更全，目前支持vc6,vc.net,devcpp,gcc,Code::Blocks,bc5，基本囊括了流行的C/C++編譯器

支持整體theme，可以一次性設(shè)置當前界面的theme

打算引入一個叫cairo的庫，具體作用好像是用于矢量運算的，屬于第三方的代碼，在fltk的站點上關(guān)于這個有一個投票，大多數(shù)人還是拒絕在fltk中加入外來插件，都覺得應(yīng)該保持fltk的輕量快速的特征

待續(xù).....

　　先看這個文章，“最小接口”：
http://blog.csdn.net/mfowler/archive/2006/10/19/1340364.aspx

　 　Martin Fowler的確是oo的大師，對類的理解和解析的確很深入，但是我還是想表述一些不同的意見。對于class而言，越強大就會越臃腫，越簡單就會越零 碎，這是不可避免的問題。對于一個足夠復(fù)雜的系統(tǒng)，class簡單了不行，太散，最后的組裝成本會相對過高，復(fù)雜了也不行，復(fù)用和維護的成本也很高。而且 這兩種都會造成中間層的脂肪過剩，雖然所有講oo的書都會說過度復(fù)雜的中間層不好，但是沒有哪本書提出了很好的解決辦法，似乎歸結(jié)到最后就只有依靠開發(fā)者 本身了。這種情況其實很是可怕，面對目前的開發(fā)現(xiàn)狀，很多系統(tǒng)對復(fù)用的渴求會越來越明顯，但是老系統(tǒng)中到底有多少模塊可以無縫移植，只怕沒有人能說清楚。 而且隨著需求的變化，老系統(tǒng)的維護和升級也越來越成為一個巨大的負擔，重寫是最常見的最終武器，但這武器所帶來的損耗和浪費也是相當驚人的。

　 　其實問題的核心是：如何在復(fù)雜度和可讀性之間尋求最佳的平衡。人的腦容量是有限的和有差異的，不同的開發(fā)者對復(fù)雜度的衡量標準是不一樣的。一個確定的模 塊，對某些人而言是容易理解和消化的，但對另外的人而言卻復(fù)雜的無法吞咽，這是現(xiàn)實問題，并不是通過培訓(xùn)和努力就能消除的。不同的行業(yè)和不同的開發(fā)方向， 一定會造成不同的理解范圍和理解方式，也就造成不同的開發(fā)者之間會存在必然的差異。只要這種差異存在，之前所述的問題就一定存在。

　　問 題不可怕，可怕的是不敢去面對。真的勇士，敢于直面慘淡的人生;-) 個人看法，膠合層是一定要減肥的，但是如何減是一個問題。對于一個oo構(gòu)架的系統(tǒng)，膠合層是一定存在的，如何做薄做小是個關(guān)鍵，同時薄和小的標準也是因人 而異的。起碼有一點我很肯定，膠合層的復(fù)用性是很差的，甚至可以說根本沒有復(fù)用的可能，那么很簡單，一個系統(tǒng)中只創(chuàng)建一個膠合層，盡量將特定的需求和無法 復(fù)用的部分整合進來，同時隨時做好丟棄的準備，一旦需要開發(fā)新系統(tǒng)或者需要升級系統(tǒng)，膠合層就成為第一個被犧牲的對象，如果設(shè)計的好，就有可能是唯一需要 丟棄的部分，這樣起碼可以保證智力投資最大限度的保值。

　　模塊(class，接口，函數(shù)，隨便你怎么定義它)的復(fù)用性如何，決定了它的 生存時間，也直接反應(yīng)了開發(fā)者的能力，如何確保復(fù)用性是個老生常談的話題了，但我還是要啰嗦兩句。復(fù)用性好并不代表強大和復(fù)雜，為了追求一個萬能模塊而編 寫足夠復(fù)雜的模塊，純屬浪費時間和精力，簡單是保證良好復(fù)用性的前提，一個復(fù)雜的模塊是不能指望有多少復(fù)用性的。同時，簡單并非是簡化，一個無法完成分內(nèi) 工作的模塊是殘次品，是不能稱之為具有復(fù)用性的。基于之前的論述，如何算是簡單對于不同的開發(fā)者而言又是各不相同的，這需要開發(fā)者從別人的角度考慮和長時 間的自我衡量，復(fù)雜了不行，學(xué)習難度太高，簡單了不行，會降低模塊的靈活性。曾經(jīng)看過一段話：好的界面就是一眼看過去，需要的功能都在，沒有什么復(fù)雜的存 在，但是需要深入控制的時候，該有的也都能找的到。挪到我們的問題上，也就差不多是這個意思了。這很難，但就是因為難，也就同時創(chuàng)造了樂趣，做為一個開發(fā) 者，當以這種困難為敵手，圖窮匕首現(xiàn)，五步濺血.....

2006-10-19 18:57

偉大的progame 11:30:40
我又在看我2年多前的代碼 向自己學(xué)習
偉大的progame 11:30:50
原來我處在一個極端 現(xiàn)在在另一個極端
量大的老鴇 11:32:14
我3年前的代碼，只能形容為：不忍卒讀
量大的老鴇 11:32:43
現(xiàn)在的代碼，可以很公正的說：垃圾
偉大的progame 11:33:07
我原來走標準的三層 com+ businessobject
偉大的progame 11:34:15
現(xiàn)在是framework + xml
偉大的progame 11:34:28
接下來要中和了
偉大的progame 11:34:31
兩個都是極端
老漁翁 11:34:57
標準的三層是垃圾。
量大的老鴇 11:37:01
我以前是標準的萬物皆類，一個小小的接口都要用類來包裹一番，結(jié)果累的不行
量大的老鴇 11:38:05
現(xiàn)在終于幡然悔悟，明白鳥手中無刀，心中有刀的真諦，所謂放下屠刀，立地成佛啊.....
偉大的progame 11:38:33
你不明白 你沒有涉及到復(fù)雜多變的業(yè)務(wù)
量大的老鴇 11:39:30
以史為鑒，展望未來，我們的目標是飛花摘葉，皆可傷人，要做到手中無刀，心中也無刀.....
烏鴉 11:39:50
粒度看自己把握
量大的老鴇 11:40:05
我堅持認為，復(fù)雜的需求未必一定帶來復(fù)雜的實現(xiàn)
老漁翁 11:40:36
我一直用成熟的技術(shù)，不用最先進的技術(shù)。
烏鴉 11:40:44
復(fù)雜的實現(xiàn)必帶來不穩(wěn)定
量大的老鴇 11:40:53
葵花寶典為什么那么nb？化繁為簡，一根繡花針就搞定一切啊
老漁翁 11:40:57
這是為什么很多國家不修磁懸浮的原因。
烏鴉 11:41:10
復(fù)雜的東西必帶來不可靠
量大的老鴇 11:41:46
再看獨孤九劍，關(guān)鍵就在一個破字
烏鴉 11:42:02
以前是數(shù)據(jù)庫,非要怎么設(shè)計
烏鴉 11:42:15
現(xiàn)在是類
烏鴉 11:42:23
然后又是層
量大的老鴇 11:42:34
所謂九賤齊出，群處可破.....
偉大的progame 11:43:41
沒說實現(xiàn)要復(fù)雜
偉大的progame 11:43:53
但是你如何有一個靈活的東西去面對多變的業(yè)務(wù)呢
偉大的progame 11:44:08
最后發(fā)現(xiàn) 事實上是很難面對的
量大的老鴇 11:44:09
要靈活，就要簡單
偉大的progame 11:44:32
想一個東西通吃不同的業(yè)務(wù)是不現(xiàn)實的
烏鴉 11:44:33
很多業(yè)務(wù)其實實現(xiàn)的代價遠遠大于維護的代價
烏鴉 11:44:43
所以這個業(yè)務(wù)實際上是錯的
量大的老鴇 11:44:44
越內(nèi)斂，越通用
偉大的progame 11:44:48
首選是業(yè)務(wù)模型的建立
偉大的progame 11:45:01
這不比軟件架構(gòu)的設(shè)計簡單
量大的老鴇 11:45:06
所謂濃縮的就是精華
量大的老鴇 11:45:49
個人經(jīng)驗：要從人的角度考慮，就可以避免一些不必要的復(fù)雜
量大的老鴇 11:46:48
幾乎所有的windows程序都有搜索，但你看linux的做法，find+grep搞定一切
偉大的progame 11:46:50
你不精通業(yè)務(wù) 再怎么設(shè)計 都可能走入死角
量大的老鴇 11:47:17
業(yè)務(wù)為人而存在
偉大的progame 11:47:32
業(yè)務(wù)第一 軟件第二
量大的老鴇 11:47:48
人第一，業(yè)務(wù)第二，軟件第三
量大的老鴇 11:48:26
表認為客戶都是笨蛋，其實當你愿意教他的時候，客戶會比你想像的聰明
偉大的progame 11:48:49
你從每個人的想法出發(fā)是錯誤的 因為即使是一個客戶 在它的內(nèi)部也是有大量的沖突
偉大的progame 11:49:00
操作和管理層 市場和售后服務(wù)
偉大的progame 11:49:12
他們的出發(fā)點是不同的 出來的東西是矛盾的
量大的老鴇 11:49:17
沖突是一定的，而且一定會造成矛盾的需求
偉大的progame 11:49:26
你如果精通業(yè)務(wù) 有成功案例
偉大的progame 11:49:33
那么好辦了 這時才可以指導(dǎo)它
量大的老鴇 11:49:50
在這個時候，可以給出一個二義性的解決方案，有何不可？
偉大的progame 11:49:58
不會因為你的軟件多么多么地靈活 多么多么地先進 你才有資格指導(dǎo)它
偉大的progame 11:50:23
那么你的軟件最后給他們是帶來問題
偉大的progame 11:50:27
而不是解決問題
量大的老鴇 11:50:37
解決問題的核心是解決人
專彈金屬的JJ 11:50:43
因為人本身，就是一個問題！
量大的老鴇 11:50:44
而不是事情
偉大的progame 11:50:53
精通業(yè)務(wù) 成功案例 這是順利實施的不二法門
偉大的progame 11:51:59
其它都是扯蛋 跟客戶說技術(shù)先進 負載量 可伸縮性 跨平臺 節(jié)約成本 最后都會因為流程無法順利走通而完蛋
量大的老鴇 11:52:21
我沒有做過數(shù)據(jù)庫應(yīng)用，所以只能從我的經(jīng)驗進行推論，未必正確，但是（我恨這個詞），一些原理也許可以通用
偉大的progame 11:52:21
老夢你做的是提供功能性的東西 功能有了 就OK了
偉大的progame 11:52:30
我做的是業(yè)務(wù)流程的東西
偉大的progame 11:52:40
流程才是最重要的
量大的老鴇 11:52:54
流程走不通，可以變通
量大的老鴇 11:53:03
變通的基點就是人
偉大的progame 11:53:16
客戶不是要你拿他來當實驗品
量大的老鴇 11:53:23
否則就不能轉(zhuǎn)化為最終實現(xiàn)
量大的老鴇 11:53:49
客戶是上帝，是豬，是畜生
量大的老鴇 11:54:08
當一回試驗品也沒關(guān)系
量大的老鴇 11:54:43
要敢于摸著mimi找mm
量大的老鴇 11:54:58
只要爽就可以
偉大的progame 11:55:17
所以沒辦法 只好犧牲幾個試驗品了
偉大的progame 11:55:25
代價就是被客戶罵
量大的老鴇 11:55:32
沒人敢說他的模型是萬能的，他的流程是通用的
量大的老鴇 11:56:09
如果能做到盡量靈活，也能做到無限接近正確
量大的老鴇 11:56:52
寫的再多，不如抓住核心
偉大的progame 11:57:21
我現(xiàn)在就是想 用底層的東西 能夠大大節(jié)省開發(fā)時間 這樣 無需開發(fā)通用產(chǎn)品 而是快速開發(fā)多個產(chǎn)品
量大的老鴇 11:58:22
也許我更粗暴，我想用進程＋靈活的接口方式，提供一勞永逸的模塊，將來的事情就是組裝
量大的老鴇 11:58:57
沒有膠合層，拒絕轉(zhuǎn)發(fā)
量大的老鴇 11:59:16
界面都可以拋棄，只有功能永存
量大的老鴇 12:00:24
所謂的框架、模型、接口，最終的目標是功能，如果帶來的附加部分遠超過實際所需，那么再先進也是廢物
量大的老鴇 12:01:05
最極端的例子就是java的那些狗屁框架，也不知道是為什么樣的腦袋而準備的
量大的老鴇 12:01:43
我只要一杯水，卻給我送上來一個凈水處理工廠

?

2006-06-29 http://www.heybrain.com 首發(fā)