或许我们可以用Vala来处理GUI,用C处理底层事务? C根本不是GUI的料,如果大家一致反对,也就PASS吧。。 > mono 是 ms 认可的 .net 的 linux 移植版 大家都知道,MS巴不得MONO赶紧死掉 > > mono项目 包含了 .net 运行时 以及 开发环境 > > 还有火狐 sliverlight plugin 也是 mono项目 的 moonlight > > ms 的官方网站上面的 slivelight 的火狐 plugin 的连接就是 moonlight > > vala 相当于 GOBJECT的 C#绑定 底层还是 GOBJECT Vala准确说不是C#绑定,相当于Gobject + C的一种预处理器 > > 印象里面 vala 不存在运行环境的问题 > > 但是也是存在 复杂的依赖关系 复杂倚赖关系是从GTK以来就有的,GNOME一个平台依赖全部都复杂 > > 两个在语法上面没有太大区别 都是使用了 类似 C# 的语法规则 > > 当然 mono 还可以运行 vb F# c++ 等其他 dotnet 语言 > > 不过 觉得 mono 资料 要比 vala 的健全一点 这个不反对 > > 所以 提议的是 mono > > python 虽然在linux发行版中 一般都已经安装 > > 但是版本不一 同时 pygtk pyqt 不一定是标准安装 > > 库的依赖关系可以通过 打包解决 deb rpm 都有相应的解决方案 > > 编译安装 很多软件 都必须安装相应的开发库 同样的情况 > > 不过 如果是真的作出一个 gnome 环境下面的 软件 > > 首选的 肯定是 gtk+ 其次就是 gtkmm+ > > 其他的总是存在 或多或少的问题 与不容易实现的部分 > > ======================================================= > > 现在项目需要的是一个比较完整的体系 > > 确定需求 比其他神马都重要 > > 同时 让每个人 明白需求也同样重要 > > 然后是分工合作 模块独立 不要畏惧连接模块的工作 > > 如果 遵循设计模式 这个不是特别困难的事情 > > 现在 项目已经基本混乱了 进行下去很困难了 > > 在使用 gtkmm 的时候 我已经实现了主面版的界面以及大部分逻辑功能 > > 但是 项目发生变化 代码无效了 这个实在是对不起了 > > Mike Ma 你是主要的项目发起人 > > 你首先要有一个相当清楚的思路 给大家明确的信息 > > 这个样子大家才能工作 > > vala 属于你熟悉的领域 但是不代表大家都需要进行再次学习 准确说我也不熟悉 > > vala 的语言结构并不复杂 但是他的库 能符合项目的要求么 能一定找到解决方案么 这个不用担心,VALA可以直接调用C库 > > 我这次说话很重 但是我觉得有必要来这么一次谈话 > > 我一直很感兴趣这个项目 希望这个项目能够成功 达到像openfetion一样的高度 > > 如果 能像 ubuntu tweak 那样成功基本也是一个梦想 > > ================================================= > > 对于 这个项目 我给一个我自己的完整思考 > > 我希望 这个项目是一个比较纯粹的 单一协议的 IM > > 这个样子 在小团队中的设计中不会出现太多问题 > > 如果 要做成多协议的 IM 一般都会顾此失彼 做成协议的最小公共子集 > > 不管 是要做成什么 都可以参考现在已经存在的项目 > > 分析出别人的实现 同时也可以为别人 已有的成熟理念进行修正 > > 这个样子就算最终的项目没有成型 但是也算奉献了开源的成果 > > 大家 还是需要分工合作 最终交换检查与测试 > > 不过这个是建立在 已经有明确的功能分析上 有确定的 API 商定的基础上的 > > 我们现在 需要的是讨论 确定各种相关问题 > > 而不是 在一个随时都在变动的项目上面消耗编写代码的时间 > > 还有 Mike Ma 告诉大家一个目标 是告诉大家 > > 而不是 通知大家 > > 让大家为这个目标奋斗 > > 以上的观点 来自个人 可能过于偏激 > > 希望 能够谅解 = = > > 在 2011年3月11日 下午9:25,Mike Ma <zhtx10@xxxxxxxxx > <mailto:zhtx10@xxxxxxxxx>>写 道: > > 我错了。。其实Mono的C#和Vala语法都是类似的,C#和Vala的一大优点是类 > 似C/C++,会很熟悉~ > (然后C#要用GTK#,不还是GTK?还要个RUNTIME,还真麻烦,虽然比JAVA快) > > python的调试我觉得还真麻烦,没有变量定义啊!而且运行效率不怎么地 > (虽然比MONO快) > > 于 2011年03月11日 21:06, Mike Ma 写道: >> python/mono运行效率低 >> python在各种linux上是标配,没问题,就是mono还要一堆依赖,跟java一 >> 样。。。 >> >> vala是纯C代码 >> >> 于 2011年03月11日 13:46, Eros 写道: >>> python 不错啊 pygtk pyqt 都行 >>> >>> 如果是 vala 不如直接使用 mono = =+ >>> >>> 在 2011年3月10日 下午10:17,Mike Ma <zhtx10@xxxxxxxxx >>> <mailto:zhtx10@xxxxxxxxx>>写 道: >>> >>> 于 2011年03月10日 21:19, Iven Day 写道: >>>> 追求开发效率的话,既然可 以用 Vala,那何不用 Genie 呢? >>>> 另外观察 GKiu 的开发,感觉技术换得很勤啊,汗…… >>>> >>>> 在 2011年3月10日 下午9:05,Mike Ma <zhtx10@xxxxxxxxx >>>> <mailto:zhtx10@xxxxxxxxx>>写 道: >>>> >>>> C语言开发效率实在不敢恭维,所以我们看到有很多东西都是 >>>> Python + PyGTK开发的。 >>>> 如果大家倾向于OOP,不知道大家认为Vala语言怎么样 (最好 >>>> 的一点是,不必手动 >>>> 管理内存了,可以用类C++的*引用*机制)? >>>> 提议C++的一律抹杀,因为GKiu就是从C++的转化过来 的。 >>>> 虽然需要重写代码,但是还是相当简单的,只是把不易理解的 >>>> 代 码改成易于理解的 >>>> 代码(见valadoc.org <http://valadoc.org>)。 >>>> 开发效率可以从DeskQ里面看到。 >>>> >>>> 大家是喜欢C一点还是喜欢OOP呢? >>>> >>>> -- >>>> Mike. >>>> Blog: http://ekd123.org/ >>>> Fedora Project Contributor - Translator. >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> Wanna be the biggest dreamer~ >>>> K.I.S.S: http://www.kissuki.com/ >>> 为了方便开发嘛,现在麻烦将来轻松 >>> 观察一下iceplayer的代码,我立马就汗了。。。 >>> 不想成为下一个iceplayer,而且C的开发效率确实很低很低很 >>> 低。。。。就 GString都要手动回收内存 (这个 最烦)。 >>> >>> -- >>> 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. > > > > > -- > 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.