关于桌面界面和插件设计思想
2008-02-12 22:12
190 查看
关于桌面界面开发:
Desktop版本的界面换语言啦!
原先考虑的JavaFX,熟悉了一个星期。
它是一个动态脚本语言,理论上是可以作出更快速的开发,和Java类的互操作也有问题。
可惜,目前的IDE(NetBeans IDE)不能把它的优势完全发挥出来,连开发JavaFX的NetBeans插件都是Beta版本的- -
相比较,应该选择Swing。
所以今天早上我把桌面版本的界面重新做了下设计,原型已经出来了。
下午结合辞典引擎的服务,已经可以搜索词汇了 :-)
不过,目前问题比较大的是性能问题,和上次讨论的结果一样,性能问题出来了。
试验中,我加载了两部辞典(物理大小20.4Mb,词汇共计62万左右),索引文件完全加载后程序运行起来至少耗费50Mb内存。。。。
关于索引的部分必须要重新设计一下!
到目前为止,我们的第一轮迭代基本完成了(14号迭代0结束,刚好2个星期),大家要注意关注项目管理中心的素材、任务、缺陷、Issue的计划。
关于支持Plugins的设计思想:
现在的词库引擎核心是Fixed和Dynamic两类。Fixed下目前只有StarDict的查询引擎;Dynamic下有基于XML的查询/编辑引擎。
我觉得可以把Fixed类型的词库查询引擎做成支持插件的设计,可以让其他开发人员扩展查询引擎。举个例子:
1. John开发了一个支持dict.org辞典格式的引擎
2. Vanessa开发了一个可以在WikiPedia上搜索词汇的引擎
他们的引擎都实现了Fixed类型引擎的接口并编译成了Jar包,我们的辞典框架可以方便地选择所需要的辞典引擎。对用户来说,可能就是在下载词库 引擎Jar后点,在StongeAge的词库引擎管理界面里来个"Install Query Engine",以后可以方便地 选择/反选/卸载 各种引擎。只要词库查询引擎够数量,世界上还有什么单词查不到的呢?这大大方便了用户!
上面只考虑了Fixed类型的词库查询,因为Fixed的查询方法前人已经有辞典格式/搜索服务接口来规定了,要作edit是不可能的。
但,这至少有两个优点:
1. 我们可以集中努力去做Open & Real-time的特性
2. 让其他开发词库引擎的开发者可以更专注地做好Fixed类型搜索
以上只是目前的想法,技术方面也作了一些研究:
OSGi4.1,eclipse3.x用的就是这个规范(基于Equinox框架)
这个是Java插件设计目前在业界据说使用最好的,但技术本身的复杂度还需要继续一定时间来实验。
好了,今天又罗嗦了一推,还是那句话:大家要积极讨论啊,交流有益身心健康:-)
Desktop版本的界面换语言啦!
原先考虑的JavaFX,熟悉了一个星期。
它是一个动态脚本语言,理论上是可以作出更快速的开发,和Java类的互操作也有问题。
可惜,目前的IDE(NetBeans IDE)不能把它的优势完全发挥出来,连开发JavaFX的NetBeans插件都是Beta版本的- -
相比较,应该选择Swing。
所以今天早上我把桌面版本的界面重新做了下设计,原型已经出来了。
下午结合辞典引擎的服务,已经可以搜索词汇了 :-)
不过,目前问题比较大的是性能问题,和上次讨论的结果一样,性能问题出来了。
试验中,我加载了两部辞典(物理大小20.4Mb,词汇共计62万左右),索引文件完全加载后程序运行起来至少耗费50Mb内存。。。。
关于索引的部分必须要重新设计一下!
到目前为止,我们的第一轮迭代基本完成了(14号迭代0结束,刚好2个星期),大家要注意关注项目管理中心的素材、任务、缺陷、Issue的计划。
关于支持Plugins的设计思想:
现在的词库引擎核心是Fixed和Dynamic两类。Fixed下目前只有StarDict的查询引擎;Dynamic下有基于XML的查询/编辑引擎。
我觉得可以把Fixed类型的词库查询引擎做成支持插件的设计,可以让其他开发人员扩展查询引擎。举个例子:
1. John开发了一个支持dict.org辞典格式的引擎
2. Vanessa开发了一个可以在WikiPedia上搜索词汇的引擎
他们的引擎都实现了Fixed类型引擎的接口并编译成了Jar包,我们的辞典框架可以方便地选择所需要的辞典引擎。对用户来说,可能就是在下载词库 引擎Jar后点,在StongeAge的词库引擎管理界面里来个"Install Query Engine",以后可以方便地 选择/反选/卸载 各种引擎。只要词库查询引擎够数量,世界上还有什么单词查不到的呢?这大大方便了用户!
上面只考虑了Fixed类型的词库查询,因为Fixed的查询方法前人已经有辞典格式/搜索服务接口来规定了,要作edit是不可能的。
但,这至少有两个优点:
1. 我们可以集中努力去做Open & Real-time的特性
2. 让其他开发词库引擎的开发者可以更专注地做好Fixed类型搜索
以上只是目前的想法,技术方面也作了一些研究:
OSGi4.1,eclipse3.x用的就是这个规范(基于Equinox框架)
这个是Java插件设计目前在业界据说使用最好的,但技术本身的复杂度还需要继续一定时间来实验。
好了,今天又罗嗦了一推,还是那句话:大家要积极讨论啊,交流有益身心健康:-)
相关文章推荐
- 关于桌面界面和插件设计思想
- 关于桌面界面和插件设计思想
- 关于桌面界面和插件设计思想
- 关于软件系统架构设计的一些新思想
- 关于android Widgets桌面小插件的开发大概流程
- 借鉴 C# 关于 LINQ 的设计思想用 C++ 11 来实现 LINQ to Object
- eclipse安装插件 windowbuilder --- 可视化swing设计界面
- Swing界面设计工具的基本思想和技术
- 关于Eclipse上使用可视化设计界面(Java EE 使用可视化界面设计)
- 一道关于简单界面设计的练习题
- 关于Windows 8系统 误删 Metro界面中的桌面或DeskTop(其他应用类似)的恢复
- eclipse安装插件 windowbuilder --- 可视化swing设计界面
- 征求关于java编程思想的教学材料(教学设计文档、PPT等)
- 关于Android app首次安装完成后在安装界面直接“打开”应用再按home键返回桌面,重新进入app重复实例化launcher activity的问题的解决
- 软件界面设计思想方法
- 关于类似RichEdit控件的设计思想
- 关于vs2008中QT插件界面生成文件(generatedfiles)的红色标记
- 关于C#自定义控件 界面设计器无法看到
- 关于android界面设计排版比例
- 关于APP界面布局设计的八种优缺点