写了一个大概。。 有什么缺少的,请提出建议~~ 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.