[gqq] Re: [gqq] 新的工作目标

  • From: Eros <authurg@xxxxxxxxx>
  • To: gqq@xxxxxxxxxxxxx
  • Date: Wed, 16 Mar 2011 21:39:21 +0800

1.功能扩展不可能是全部dbus实现吧 (虽然理论上是可以的) 还是要提供插件的接口C函数

2.这个架构莫不是 MVC?

3.界面这个 只要底层提供合适的接口函数 就可以直接包装起来吧

4.写到这里的时候 在想能不能

协议层 实现核心控制层的功能需求

核心控制层 (1)管理协议(2)提供插件的支持以及接口(3)提供功能的对外接口(接入图形控制层)(4) 这里也提供dbus的支持

界面控制层 (1)反映界面功能需求 管理界面 (2)实现界面对核心控制层的调用 (3)同时也提供插件的图形化整合接口

界面层  实现界面 以及实现界面的基本逻辑与实际功能(通过调用界面控制层的函数)

这个样子的好处是 协议层 与 核心控制层 是一个持久结构 一旦功能稳定可以不必改动 只需要优化

而 界面控制层 可以使得界面完全拆卸 如果有需求只需要重新实现界面控制层与界面就可以使得界面焕然一新 满足需求

同时 如果插件在图形界面需要表现 这个样子可以可以满足插件的图形开发

再说  这个样子就是很具有层独立的感觉 耦合度很低了 只要是协议层 与 核心控制层 能够用Linux c实现了

其他 部分就看个人喜好了

觉得怎么样

这个样子不会被说是效率问题吧 包装层数太多了?

但是 开发效率以及难易程度也很重要啊

在 2011年3月15日 下午9:50,Mike Ma <zhtx10@xxxxxxxxx>写道:

> 目前的GUI不方便拓展也不利于美化,不如做成这样
>
> /* 在等宽字体下察看 */
> 插件-> 管理器 <-IM层
> |
> GUI
>
> 在管理器中提供一些接口,比如(如果不满意,大家也可以想想,比如只有一个
> data之类的)
> im_t request_im (const char *im_name, void *data1, void *data2, void
> *data3);
> int call_im (im_t im, action_t action, void *data1, void *data2, void
> *data3);
> interface_t request_plugin (const char *plugin_name, void *data1, void
> *data2, void *data3);
> int call_interface (interface_t interface, action_t action, void *data1,
> void *data2, void *data3);
> 像这样,或许能更简单,也可以解决大家的语言纠结,比如在性能要求较高的管理
> 器层用C写,在IM层、GUI层用C++写之类的(各得其所嘛~ 皆大欢喜~)。
> 如果是python等其他不支持C/C++类似的调用的语言,可以再支持一个dbus在比较
> 复杂的环境下。
> *
> * 不如这样
> * 把interface_t做成接口,第一个数据就是“是否dbus”
> *
> * 或者是,接口完全dbus实现,但是开销会不会大点?我还不了解DBus
> *
>
> 建议是,
> 1. 首先砍掉目前的GUI
> 2. 将现有代码进行整理
> 3. 确定需要提供的接口*
> 4. 实现插件
>
> 讨论此贴。。。
> 同样,不同意就忽略。。。
>
> --
> Mike.
> Blog: http://ekd123.org/
> Fedora Project Contributor - Translator.
>
>
>


-- 
I'm Authur.

Mail: authurg@xxxxxxxxx authurg@xxxxxxxxxxx authurg@xxxxxxxxx
Blog: www.dark-cloud.org

我只是在代码中爬行的一只虫子...

Other related posts: