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

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

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

     摘要: 先貼一段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的跨平臺(tái)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下，當(dāng)FLTK界面包含中文的時(shí)候，打開程序的時(shí)候會(huì)花費(fèi)好幾秒的時(shí)間才能完整顯示界面

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

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

所以我做了修正，每當(dāng)需要  閱讀全文

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

群號(hào)：32425450

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

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

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

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

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

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

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

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

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

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

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

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

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

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

待續(xù).....

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

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

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

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

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

2006-10-19 18:57

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

?

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