[gqq] Re: 新的工作目标

  • From: Mike Ma <zhtx10@xxxxxxxxx>
  • To: Devil Wang <wxjeacen@xxxxxxxxx>
  • Date: Sat, 19 Mar 2011 18:40:57 +0800

写了一个大概。。
有什么缺少的,请提出建议~~
emacs打开能看到高亮格式,TAB TAB展开全部节点。。

于 2011年03月19日 18:36, Devil Wang 写道:
> *
> *
> 2011/3/19 Mike Ma <zhtx10@xxxxxxxxx <mailto:zhtx10@xxxxxxxxx>>
>
>     掂量了一下,好像必须GModule/DBus两者都用,前者GModule接口载入,处
>     理DBus模块,后者DBus接口调用
>
>     目前在写相应文档(Core部分)(Emacs ORG-MODE格式)
>     等完成后放出。。。
>
>
> 写完发出来大家review下。
>
>     于 2011年03月17日 13:25, Mike Ma 写道:
>>     这个提议对大家都有好处。。
>>     可拆卸 - 可移植 - 易拓展 - 开发简易
>>     集X好处于一身啊
>>
>>     于 2011年03月16日 21:39, Eros 写道:
>>>     1.功能扩展不可能是全部dbus实现吧 (虽然理论上是可以的) 还是要提
>>>     供插件的接口C函数
>>     这个当然咯
>>>
>>>     2.这个架构莫不是 MVC?
>>     有点类似吧
>>>
>>>     3.界面这个 只要底层提供合适的接口函数 就可以直接包装起来吧
>>
>>>
>>>     4.写到这里的时候 在想能不能
>>>
>>>     协议层 实现核心控制层的功能需求
>>     我的打算是全部类似插件的功能
>>>
>>>     核心控制层 (1)管理协议(2)提供插件的支持以及接口(3)提供功能
>>>     的对外接口(接入图形控制层)(4) 这里也提供dbus的支持
>>     这个不需要管理协议吧。。只是提供一个接口,还是在插件层管理?
>>     再提供一个插件层?
>>>
>>>     界面控制层 (1)反映界面功能需求 管理界面 (2)实现界面对核心控
>>>     制层的调用 (3)同时也提供插件的图形化整合接口
>>>
>>>     界面层 实现界面 以及实现界面的基本逻辑与实际功能(通过调用界面控
>>>     制层的函数)
>>>
>>>     这个样子的好处是 协议层 与 核心控制层 是一个持久结构 一旦功能稳
>>>     定可以不必改动 只需要优化
>>>
>>>     而 界面控制层 可以使得界面完全拆卸 如果有需求只需要重新实现界面
>>>     控制层与界面就可以使得界面焕然一新 满足需求
>>     我的打算就是这样的~~
>>     和X差不多的哈~
>>>
>>>     同时 如果插件在图形界面需要表现 这个样子可以可以满足插件的图形开发
>>     当然~比如QQ需要截图之类的东东。
>>>
>>>     再说 这个样子就是很具有层独立的感觉 耦合度很低了 只要是协议层 与
>>>     核心控制层 能够用Linux c实现了
>>     同感,想体现UNIX的哲学
>>>
>>>     其他 部分就看个人喜好了
>>>
>>>     觉得怎么样
>>>
>>>     这个样子不会被说是效率问题吧 包装层数太多了?
>>     这个。。CPU速度越来越快也越来越不是问题了。。。
>>     何况aMSN还是Tcl写的, EMESENE还是Python写的。
>>>
>>>     但是 开发效率以及难易程度也很重要啊
>>     除了接口确定需要长时间的开发才等确定
>>     接下来的就都是插件了,当然简单了(规模小,大多功能也是封装的)
>>>
>>>     在 2011年3月15日 下午9:50,Mike Ma <zhtx10@xxxxxxxxx
>>>     <mailto: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 <mailto:authurg@xxxxxxxxx>
>>>     authurg@xxxxxxxxxxx <mailto:authurg@xxxxxxxxxxx>
>>>     authurg@xxxxxxxxx <mailto:authurg@xxxxxxxxx>
>>>     Blog: www.dark-cloud.org <http://www.dark-cloud.org/>
>>>     我只是在代码中爬行的一只虫子...
>>>
>>
>>     -- 
>>     Mike.
>>     Blog: http://ekd123.org/
>>     Fedora Project Contributor - Translator.
>
>     -- 
>     Mike.
>     Blog: http://ekd123.org/
>     Fedora Project Contributor - Translator.
>
>
>
>
> -- 
>
> */
>
> Best Regards,
>
> Devil Wang
>
> /*

-- 
Mike.
Blog: http://ekd123.org/
Fedora Project Contributor - Translator.

Other related posts: