随笔 - 16, 文章 - 0, 评论 - 55, 引用 - 0
数据加载中……

2015年11月1日

fltk剖析 main-loop(二)

     摘要: 基本上,fltk认为所有的操作系统都会提供以下几种功能:
1.窗口创建和销毁
2.绘图(点,直线,曲线,圆...)
3.字体显示
4.输入设备交互(键盘、鼠标)

只要有这几种功能,不需要系统提供全套的控件,也可以自行构建出界面。另外系统还会提供一些附加功能,对于丰富界面也很有帮助,但并不是充分必要条件,比如
1.图片读写
2.文件操作
3.打印机
4.输入法

基于这样的认知,做为一个GUI库,fltk需要提供一个模型,把这些元素组合在一起,既要有足够的弹性又要足够简单  阅读全文

posted @ 2015-11-01 11:58 cyantree 阅读(1412) | 评论 (0)编辑 收藏

2015年10月19日

fltk剖析 (一)

     摘要: 先贴一段fltk的官网介绍:

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++界面库,尺寸精简,具有现代GUI功能,支持OpenGL,内置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   阅读全文

posted @ 2015-10-19 23:52 cyantree 阅读(1413) | 评论 (0)编辑 收藏

2015年10月18日

修正fltk 1.3在crunchbang linux下无法调用输入法的问题

在fl_open_display()中添加以下两句:
// Add by cyantree, for root-window ime
if (!XSupportsLocale()) {
//(void) fprintf(stderr, "%s: X does not support locale %s.", program_name, setlocale(LC_ALL, NULL));
//exit(1);
}
if (XSetLocaleModifiers("") == NULL) {
//(void) fprintf(stderr, "%s: Warning: cannot set locale modifiers.", argv[0]);
}


原因是在crunchbang linux下面输入法是root-window模式,所以需要这么设置,至于什么是root window,可以参考x11的说明
另外在Elementary OS下面还是不能调用输入法,估计原因是差不多的,但是修正方法还不够,有空的时候再说,最近在折腾android移植到fltk,没什么时间

posted @ 2015-10-18 23:46 cyantree 阅读(713) | 评论 (0)编辑 收藏

2014年4月29日

在windows下,当FLTK界面上包含中文的时候启动速度很慢,以下为修正过程

     摘要: 问题描述:
在windows下,当FLTK界面包含中文的时候,打开程序的时候会花费好几秒的时间才能完整显示界面

原因:
查了代码,最后发现原因在于绘制字符的时候通过GetTextExtentPoint32W这个函数获取字符宽度,由于这个函数本身速度不够快,所以FLTK使用缓存方式来保存宽度,问题在于缓存的方式不适合中文这种宽字符,当前的缓存方式是每当获取一个字符宽度时,把这个字符左右共1024个相邻字符的宽度提前获取并保存,以后每次获取字符宽度之前先搜索缓存,如果没有再通过API实际获取。

这个做法对于英文没有问题,因为GetTextExtentPoint32W处理英文的速度很快,而且一次获取1024个相邻字符基本就把程序可能会用到的字符全部囊括了,但是当界面出现中文的时候这种做法就出现问题了,中文的字符集是很大的,一次获取相邻个1024字符宽度并不能保证囊括了绝大多数的字符,所以每次界面显示之前都会花很多时间获取很多用不到的字符宽度,虽然显示一次之后的速度很快,但是启动程序的时候会出现卡顿

所以我做了修正,每当需要  阅读全文

posted @ 2014-04-29 17:28 cyantree 阅读(1390) | 评论 (0)编辑 收藏

2012年5月13日

FLTK新手入门[翻译]

     摘要: [本教程翻译自http://www3.telus.net/public/robark/]新手入门 版本: 1.1 目录更新历史目标人群知识预备为何使用FLTK编写GUI程序?获取FLTK进入FLTK基础课程 视频教程  一个简单的窗口程序(Simple Window Function)有关控件Label的陷阱(Widget Label Pitfall)  (新)控件间通讯...  阅读全文

posted @ 2012-05-13 15:01 cyantree 阅读(14416) | 评论 (8)编辑 收藏

2007年1月28日

讨论fltk的qq群

群号:32425450

欢迎对fltk有兴趣的开发人员加入

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

posted @ 2007-01-28 18:43 cyantree 阅读(1368) | 评论 (3)编辑 收藏

2007年1月23日

fltk在windows上的一个小bug

描述:
在windows下创建一个resizable window,最大化的时候会出错,窗口的最下方实际上并没有和任务栏靠在一起,而且如果任务栏很高,那更是奇怪,窗口会超出任务栏

原因:
怀疑实现部分并非是由系统处理,而且自己处理了这个事件,没有去看代码,暂时存疑

解决:
无。只有找到源代码的实现部分才知道怎么修改了

posted @ 2007-01-23 19:43 cyantree 阅读(1678) | 评论 (4)编辑 收藏

fltk2更新简介

不久前fltk终于释出可以实用的2.0版本,目前的具体版本是2.0.x-r5556,让我们看看具体的更新和变动

首先是字体 的巨大改进,开始支持utf8,所以在linux下汉字无法显示和输入法无法输入的问题已经彻底解决,但同时也带来一些问题,就是在代码内必须使用 utf8的汉字才能正确显示在界面上,但是unicode的编辑器又不是那么好找,再说在windows下开发的话一般都会使用vc,而在vc下输入 unicode是一件有困难的事情,至少我没有找到好的插件,所以需要一个解决办法,那就是里的函数,帮助文档里没 有说的很清楚,但是大体上还是可以猜到意思的

修 改了class Browser,变成了一个tree,在1.0中想显示一个grid或者listview一直只能自己处理,现在不用了,这个Browser还算可以,提 供了基本的功能,稍微还有一些扩充,如果想再丰富一些就只有自己继承了,反正fltk的宗旨就是自己动手丰衣足食。

Opengl的功能貌似有一些修正,但是我没有用到,而且demo中关于OpenGL的例子还没有提供,所以目前情况未知

帮助文档未完善,而且代码中附带的帮助无法使用,所以很多时候还是查1.0的帮助以及看源代码更加有效一些

所 有的头文件和类名全部去除了FL_,引入了namespace,好处是类看起来更清楚了,坏处是从1.0的代码升级变得很麻烦。
头文件从<FL/FL_XXXX.H>变成<fltk/xxxx.h>,全部变成了小写,而且去掉了FL_,同时目录也变成fltk/了,这些细 节稍微用一段时间就会习惯,一开始会造成一些问题,虽然在fltk目录下也保留了一些兼容的头文件,但是建议还是不要用,因为不全,而且迟早要换的, 何必不一步到位?

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

支持整体theme,可以一次性设置当前界面的theme

打算引入一个叫cairo的库,具体作用好像是用于矢量运算的,属于第三方的代码,在fltk的站点上关于这个有一个投票,大多数人还是拒绝在fltk中加入外来插件,都觉得应该保持fltk的轻量快速的特征

待续.....

posted @ 2007-01-23 19:42 cyantree 阅读(3519) | 评论 (5)编辑 收藏

2006年10月19日

class的沼泽地

  先看这个文章,“最小接口”:
http://blog.csdn.net/mfowler/archive/2006/10/19/1340364.aspx

   Martin Fowler的确是oo的大师,对类的理解和解析的确很深入,但是我还是想表述一些不同的意见。对于class而言,越强大就会越臃肿,越简单就会越零 碎,这是不可避免的问题。对于一个足够复杂的系统,class简单了不行,太散,最后的组装成本会相对过高,复杂了也不行,复用和维护的成本也很高。而且 这两种都会造成中间层的脂肪过剩,虽然所有讲oo的书都会说过度复杂的中间层不好,但是没有哪本书提出了很好的解决办法,似乎归结到最后就只有依靠开发者 本身了。这种情况其实很是可怕,面对目前的开发现状,很多系统对复用的渴求会越来越明显,但是老系统中到底有多少模块可以无缝移植,只怕没有人能说清楚。 而且随着需求的变化,老系统的维护和升级也越来越成为一个巨大的负担,重写是最常见的最终武器,但这武器所带来的损耗和浪费也是相当惊人的。

   其实问题的核心是:如何在复杂度和可读性之间寻求最佳的平衡。人的脑容量是有限的和有差异的,不同的开发者对复杂度的衡量标准是不一样的。一个确定的模 块,对某些人而言是容易理解和消化的,但对另外的人而言却复杂的无法吞咽,这是现实问题,并不是通过培训和努力就能消除的。不同的行业和不同的开发方向, 一定会造成不同的理解范围和理解方式,也就造成不同的开发者之间会存在必然的差异。只要这种差异存在,之前所述的问题就一定存在。

  问 题不可怕,可怕的是不敢去面对。真的勇士,敢于直面惨淡的人生;-) 个人看法,胶合层是一定要减肥的,但是如何减是一个问题。对于一个oo构架的系统,胶合层是一定存在的,如何做薄做小是个关键,同时薄和小的标准也是因人 而异的。起码有一点我很肯定,胶合层的复用性是很差的,甚至可以说根本没有复用的可能,那么很简单,一个系统中只创建一个胶合层,尽量将特定的需求和无法 复用的部分整合进来,同时随时做好丢弃的准备,一旦需要开发新系统或者需要升级系统,胶合层就成为第一个被牺牲的对象,如果设计的好,就有可能是唯一需要 丢弃的部分,这样起码可以保证智力投资最大限度的保值。

  模块(class,接口,函数,随便你怎么定义它)的复用性如何,决定了它的 生存时间,也直接反应了开发者的能力,如何确保复用性是个老生常谈的话题了,但我还是要啰嗦两句。复用性好并不代表强大和复杂,为了追求一个万能模块而编 写足够复杂的模块,纯属浪费时间和精力,简单是保证良好复用性的前提,一个复杂的模块是不能指望有多少复用性的。同时,简单并非是简化,一个无法完成分内 工作的模块是残次品,是不能称之为具有复用性的。基于之前的论述,如何算是简单对于不同的开发者而言又是各不相同的,这需要开发者从别人的角度考虑和长时 间的自我衡量,复杂了不行,学习难度太高,简单了不行,会降低模块的灵活性。曾经看过一段话:好的界面就是一眼看过去,需要的功能都在,没有什么复杂的存 在,但是需要深入控制的时候,该有的也都能找的到。挪到我们的问题上,也就差不多是这个意思了。这很难,但就是因为难,也就同时创造了乐趣,做为一个开发 者,当以这种困难为敌手,图穷匕首现,五步溅血.....

2006-10-19 18:57

posted @ 2006-10-19 21:15 cyantree 阅读(1562) | 评论 (2)编辑 收藏

2006年7月6日

两个bt聊天

伟大的progame 11:30:40
我又在看我2年多前的代码 向自己学习
伟大的progame 11:30:50
原来我处在一个极端 现在在另一个极端
量大的老鸨 11:32:14
我3年前的代码,只能形容为:不忍卒读
量大的老鸨 11:32:43
现在的代码,可以很公正的说:垃圾
伟大的progame 11:33:07
我原来走标准的三层 com+ businessobject
伟大的progame 11:34:15
现在是framework + xml
伟大的progame 11:34:28
接下来要中和了
伟大的progame 11:34:31
两个都是极端
老渔翁 11:34:57
标准的三层是垃圾。
量大的老鸨 11:37:01
我以前是标准的万物皆类,一个小小的接口都要用类来包裹一番,结果累的不行
量大的老鸨 11:38:05
现在终于幡然悔悟,明白鸟手中无刀,心中有刀的真谛,所谓放下屠刀,立地成佛啊.....
伟大的progame 11:38:33
你不明白 你没有涉及到复杂多变的业务
量大的老鸨 11:39:30
以史为鉴,展望未来,我们的目标是飞花摘叶,皆可伤人,要做到手中无刀,心中也无刀.....
乌鸦 11:39:50
粒度看自己把握
量大的老鸨 11:40:05
我坚持认为,复杂的需求未必一定带来复杂的实现
老渔翁 11:40:36
我一直用成熟的技术,不用最先进的技术。
乌鸦 11:40:44
复杂的实现必带来不稳定
量大的老鸨 11:40:53
葵花宝典为什么那么nb?化繁为简,一根绣花针就搞定一切啊
老渔翁 11:40:57
这是为什么很多国家不修磁悬浮的原因。
乌鸦 11:41:10
复杂的东西必带来不可靠
量大的老鸨 11:41:46
再看独孤九剑,关键就在一个破字
乌鸦 11:42:02
以前是数据库,非要怎么设计
乌鸦 11:42:15
现在是类
乌鸦 11:42:23
然后又是层
量大的老鸨 11:42:34
所谓九贱齐出,群处可破.....
伟大的progame 11:43:41
没说实现要复杂
伟大的progame 11:43:53
但是你如何有一个灵活的东西去面对多变的业务呢
伟大的progame 11:44:08
最后发现 事实上是很难面对的
量大的老鸨 11:44:09
要灵活,就要简单
伟大的progame 11:44:32
想一个东西通吃不同的业务是不现实的
乌鸦 11:44:33
很多业务其实实现的代价远远大于维护的代价
乌鸦 11:44:43
所以这个业务实际上是错的
量大的老鸨 11:44:44
越内敛,越通用
伟大的progame 11:44:48
首选是业务模型的建立
伟大的progame 11:45:01
这不比软件架构的设计简单
量大的老鸨 11:45:06
所谓浓缩的就是精华
量大的老鸨 11:45:49
个人经验:要从人的角度考虑,就可以避免一些不必要的复杂
量大的老鸨 11:46:48
几乎所有的windows程序都有搜索,但你看linux的做法,find+grep搞定一切
伟大的progame 11:46:50
你不精通业务 再怎么设计 都可能走入死角
量大的老鸨 11:47:17
业务为人而存在
伟大的progame 11:47:32
业务第一 软件第二
量大的老鸨 11:47:48
人第一,业务第二,软件第三
量大的老鸨 11:48:26
表认为客户都是笨蛋,其实当你愿意教他的时候,客户会比你想像的聪明
伟大的progame 11:48:49
你从每个人的想法出发是错误的 因为即使是一个客户 在它的内部也是有大量的冲突
伟大的progame 11:49:00
操作和管理层 市场和售后服务
伟大的progame 11:49:12
他们的出发点是不同的 出来的东西是矛盾的
量大的老鸨 11:49:17
冲突是一定的,而且一定会造成矛盾的需求
伟大的progame 11:49:26
你如果精通业务 有成功案例
伟大的progame 11:49:33
那么好办了 这时才可以指导它
量大的老鸨 11:49:50
在这个时候,可以给出一个二义性的解决方案,有何不可?
伟大的progame 11:49:58
不会因为你的软件多么多么地灵活 多么多么地先进 你才有资格指导它
伟大的progame 11:50:23
那么你的软件最后给他们是带来问题
伟大的progame 11:50:27
而不是解决问题
量大的老鸨 11:50:37
解决问题的核心是解决人
专弹金属的JJ 11:50:43
因为人本身,就是一个问题!
量大的老鸨 11:50:44
而不是事情
伟大的progame 11:50:53
精通业务 成功案例 这是顺利实施的不二法门
伟大的progame 11:51:59
其它都是扯蛋 跟客户说技术先进 负载量 可伸缩性 跨平台 节约成本 最后都会因为流程无法顺利走通而完蛋
量大的老鸨 11:52:21
我没有做过数据库应用,所以只能从我的经验进行推论,未必正确,但是(我恨这个词),一些原理也许可以通用
伟大的progame 11:52:21
老梦你做的是提供功能性的东西 功能有了 就OK了
伟大的progame 11:52:30
我做的是业务流程的东西
伟大的progame 11:52:40
流程才是最重要的
量大的老鸨 11:52:54
流程走不通,可以变通
量大的老鸨 11:53:03
变通的基点就是人
伟大的progame 11:53:16
客户不是要你拿他来当实验品
量大的老鸨 11:53:23
否则就不能转化为最终实现
量大的老鸨 11:53:49
客户是上帝,是猪,是畜生
量大的老鸨 11:54:08
当一回试验品也没关系
量大的老鸨 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
我现在就是想 用底层的东西 能够大大节省开发时间 这样 无需开发通用产品 而是快速开发多个产品
量大的老鸨 11:58:22
也许我更粗暴,我想用进程+灵活的接口方式,提供一劳永逸的模块,将来的事情就是组装
量大的老鸨 11:58:57
没有胶合层,拒绝转发
量大的老鸨 11:59:16
界面都可以抛弃,只有功能永存
量大的老鸨 12:00:24
所谓的框架、模型、接口,最终的目标是功能,如果带来的附加部分远超过实际所需,那么再先进也是废物
量大的老鸨 12:01:05
最极端的例子就是java的那些狗屁框架,也不知道是为什么样的脑袋而准备的
量大的老鸨 12:01:43
我只要一杯水,却给我送上来一个净水处理工厂

 

2006-06-29 http://www.heybrain.com 首发

posted @ 2006-07-06 23:20 cyantree 阅读(450) | 评论 (0)编辑 收藏