- 浏览: 204659 次
- 性别:
- 来自: Wgt
最新评论
-
pxiaozei:
楼主,你这样用,需要在SVN服务器上建Git服务器端么?
SVN+GIT=鱼与熊掌兼得 -
southwolf:
这个项目还在维护吗……
OpenCV+Ruby构建图像处理研究平台 -
w87848608:
请问,比如我利用git,开了一个branch A,做了功能A, ...
SVN+GIT=鱼与熊掌兼得 -
sxlkk:
callmechen 写道本质上还是没有解决合并的繁琐。换汤不 ...
SVN+GIT=鱼与熊掌兼得 -
清气上升:
本地提交,本地错误恢复,eclipse有local histo ...
SVN+GIT=鱼与熊掌兼得
ruby语言由于其灵活优雅的表达方式和优秀的OO的特性,是GUI编程语言的有力竞争者。特别是其Closure特性,能够使GUI编程时遇到的很多头痛的问题迎刃而解。
最近手上的一个项目刚好需要做一个Windows平台的GUI程序,以前是用VB,虽然VB是Windows GUI的经典工具,能够快速进行GUI原型开发,但是一旦GUI元素多起来,且UI元素存在复杂关系,就很难维护....特别在后期,一旦需求有什么变化,再去调整UI,那个叫痛苦啊。因此就想用ruby试试,加上此次项目设计很多网络通讯方面的需求,因此更加坚定了使用ruby的决心。现在项目基本完工,再回过头看,以前用VB开发时碰到的种种问题在新项目中都被很好地解决了。特别地,体会到了Closure对于GUI编程的重要性。不管未来在的GUI编程领域ruby是否能成为主流,但是可以预见那种语言一定是具备Closure(或类似)功能的。(或者只是我的美好愿望?)
GUI库选型:
ruby发行包自带TK库,用于简单的程序还可以,但是一旦有复杂界面需求时就难以满足。目前比较成熟的GUI绑定库有RubyFox,wxRuby 和 RubyGnome. 鉴于GTK用的人比较多,加上GTK在Windows上的Runtime也是比较稳定,GTK应用的代表GIMP看起来也比较漂亮,因此就选择了RubyGnome作为GUI库。
关于RubyGnome我也不多介绍,其项目主页上的文档和教程非常不错。
Ruby-Gnome项目的首页: http://ruby-gnome2.sourceforge.jp/
1. Closure 作为响应GUI消息事件
在MFC中,响应消息通常需要定义OnXXX()虚函数,而且需要在消息传递宏里面与某个消息挂上勾,然后在实现OnXXX()函数。
在VB中,IDE为你为某个控件的消息生成消息响应函数。
那么在Ruby-Gnome里面,这么做:
在这一点上,MFC最为繁琐不用说了。VB由IDE为你预先做了很多工作。ruby用代码关联“clicked”事件,用Closure作为消息响应,干净利落。
表面上看,似乎ruby的方式也未必好很多,但是且慢,看下一个....
2. Closure 里面可以访问当前上下文
GUI编程经常面临的一个头痛的问题是,UI元件通常需要是全局的,至少是窗口类内全局。例如,希望button被按下的时候改变label的内容,那么就要求在响应button事件的代码内要能够访问label。在MFC中,label被迫成为全局。在VB中,你不能控制。在界面元素很多的时候,这可能会成为一个问题--你不得不仔细地为每一个UI元件命名以防止名称冲突。
而在ruby中,由于Closure能够访问当前上下文,因此正好可以完美解决这个问题:
ruby的Closure使得代码“内聚”了,即相互关联的元素的作用域可以被限定在一个很小的范围,这样对于代码的维护和应付变化都是具有非凡的意义。
3. 动态打开一个类的能力使得扩展基类的功能变得简单
ruby能够动态地打开一个类并往里面增加method的能力已经不是什么新鲜事,对于这个特性也有很多争议。但对于GUI编程来说,这确实是提供了很大的方便。
在GUI编程中,msgbox是很常用的一个工具。在RubyGnome中,Gtk::Window没有msgbox这个接口,下面的例子就是封装了一个易用的Msgbox类,并打开Gtk::Window类,增加msgbox函数,这样所有基于Gtk::Window的类都可以随时调用msgbox:
上面的例子来源于实际项目,为了使用方便做了很多封装,后面还有一段测试代码,所以有点长。如果你也用RubyGnome开发GUI,那么这个简易的Msgbox将会带来很多方便
Ruby作为GUI编程语言现在还不会成为主流,但是其动态特性将有助于解决传统GUI编程中遇到的问题,而且随着GUI binding lib的成熟,稳定,Ruby,有望在又一个领域成为编程利器。
可以做,并不等于就有吧?C#的界面代码,已经帮你完成了80%以上的coding工作。
IDE所做的,是“设计阶段”的活。
手工写代码,建立在前者的基础上,做“运行阶段”的活,可以进行更灵活更复杂的控制和调整。
设计阶段的成果,用XML这样的标记语言存储比较好,最终作为代码执行起来。
ruby的closuer,使得它很接近标记语言,如果ui库设计的优良(比如前面提到的遵循CoC和Builder风格),IDE生成的东西和手写出来的代码应该接近一致。那么,它们的区别,更像是linux操作中,用shell还是GUI。
-- 差距减小。
我个人更喜欢GUI/IDE,因为属性、样式、事件列表可以直观看到,设置完关注的条目,还能直接看到效果。这就是IDE的威力吧。
不过,如果用IDE设计一个窗口时要设置一些东西,在做其它窗口时还要进行同样(或相似)的操作,就如同重复代码,是坏味道。代码通常用封装来消除重复,IDE操作呢?
1. 宏。如同代码生成器一样,生成起来简单 改起来难。
2. 组件封装。Flex对这方面支持的不错(.NET或许也不错吧,没研究过),可以组合其它组件,调整或定制属性、样式和事件,可以用MXML(IDE辅助)轻松完成,本质是类继承。新封装的组件能在IDE中使用。
把业务系统划分成一个个相对独立的界面部件,维护起来就爽了。VB一类的“老”式工具,对它支持不强。理想情况,我们在开发一个个“业务部件”,而不是界面。我们要表达的,只是这个部件应该提供的内容,而不是样式、技术控件之类的东西。
我觉得组件封装对人的要求比较高,要在把握业务的前提下,合理划分出组件、接口和交互关系。
识别重复操作的范围(偶然重复,局部重复,模块重复,全局重复),做出整体规划,都不是简单事。
如果以理想方式开发,由于尽可能的消除了IDE之上的重复操作,“设计阶段”的活减轻了,还有的转移成:用IDE+code开发“业务基础组件”。那么,对于逻辑简单的UI,整个开发工作量就比较小。逻辑复杂的UI,工作量转移到“运行阶段”也不足为奇。
-- 比重减小。
flex和.net都提供了data binding,相当于把一些通用UI控制逻辑也封装到了组件里,这种能力和模式,是把“本质不是运行阶段”的工作从“运行阶段”代码中提取出去。
组件的本质,殊途同归,仍然是代码级的类继承和抽象。让人充分利用IDE的同时,也需要人去理解代码和组件的映射关系。IDE的长处,是设定数据;代码的长处,是设定算法。DSL的好处,是降低两者的隔阂。(关于目前ruby DSL应用中,处理数据和算法上的问题,欢迎大家新开贴讨论)
“运行阶段”的重复,也同样需要处理。
组件的AOP,不知道有什么思路或现有方案?
可以做,并不等于就有吧?C#的界面代码,已经帮你完成了80%以上的coding工作。
连在说什么都搞不清楚,就这里发言?
高效,当然是指开发效率,手工去堆砌界面能比IDE开发效率高? 楼主那个例子已经是简单的不能在简单了,在 GUI中根本不值一提,让他用手工写个outlook的界面看看,得花多少时间。
看来语言障碍害死人啊
VB那只是一个ide的功劳吧了,ruby一样可以做一个ide,做一大堆可视化编辑
ruby的语言特性使得他用于gui编程是高效的,至少比vb是
你用vb码界面只代表ide代替你做了一些工作,而不是不需要做一些工作,别人自己写的ruby类库和代码生成器一样可以起到这个效果
这个很强!
如果有个程序员成天需要把A Control放到B Control里,那他就是个蹩脚货,或者是 写规划需求的人是个蹩脚货.
还可以进一步的说,那些老变更需求的客户就是混蛋。
这个我是第一次听说,说来听听?
大叔,偶觉得您参与搅和的这些A v.s B系列中,您颇有这篇帖子中“那人”的风采:
http://www.iteye.com/topic/235214
因为总有贴主说A vs B的时候总会有谬误,否则我怎么去抓他的小辫子。
比如最谬误的那个什么FP vs C# java, 俺以事实为依据写了一行C#完成他的狗屁FP.
高效,当然是指开发效率,手工去堆砌界面能比IDE开发效率高? 楼主那个例子已经是简单的不能在简单了,在 GUI中根本不值一提,让他用手工写个outlook的界面看看,得花多少时间。
开发软件不是光是弄个界面摆在那儿。单论界面生成,用代码当然比不上可视化IDE快。但是当界面具有复杂GUI元素,并且需要与复杂程序逻辑粘合,用代码生成界面具有更大的灵活性,比如方便动态添加/移除GUI元素,容易调整GUI结构。
其实Ruby/GTK也可以用Glade来可视化编辑界面,在实际的工程中,我一般是用Glade生成那些普通的用于展现数据的界面,而对于有复杂逻辑的,存在大量动态变化的界面,还是用代码更方便。
可视化界面编辑器可以降低GUI开发门槛,加速简单GUI界面开发。但是对于整个程序开发来说,设计良好的GUI库,语言的表达能力和某些特性(例如本文所讨论的Closure),比“拖拖拉拉”的快感更重要。
任何复杂的GUI都是由若干简单的element构成的,基本算的上掌握GUI的能力,就是应该能把element复合成一定功能control以期组合成更复杂的gui. 拖拖拉拉,不过是你对GUI最粗浅的认识而已。
所谓手工代码具备更大灵活性,完全就是个伪命题,当UI元素蜕化成XML(XUL,WPF),不再以所谓的代码耦合的时候,UI还是UI. 世界上绝大部分GUI,都是MFC的成果。
高效,当然是指开发效率,手工去堆砌界面能比IDE开发效率高? 楼主那个例子已经是简单的不能在简单了,在 GUI中根本不值一提,让他用手工写个outlook的界面看看,得花多少时间。
开发软件不是光是弄个界面摆在那儿。单论界面生成,用代码当然比不上可视化IDE快。但是当界面具有复杂GUI元素,并且需要与复杂程序逻辑粘合,用代码生成界面具有更大的灵活性,比如方便动态添加/移除GUI元素,容易调整GUI结构。
其实Ruby/GTK也可以用Glade来可视化编辑界面,在实际的工程中,我一般是用Glade生成那些普通的用于展现数据的界面,而对于有复杂逻辑的,存在大量动态变化的界面,还是用代码更方便。
可视化界面编辑器可以降低GUI开发门槛,加速简单GUI界面开发。但是对于整个程序开发来说,设计良好的GUI库,语言的表达能力和某些特性(例如本文所讨论的Closure),比“拖拖拉拉”的快感更重要。
连在说什么都搞不清楚,就这里发言?
高效,当然是指开发效率,手工去堆砌界面能比IDE开发效率高? 楼主那个例子已经是简单的不能在简单了,在 GUI中根本不值一提,让他用手工写个outlook的界面看看,得花多少时间。
有利必有弊。有时候可视化的拖拖放放反而不如写代码容易。
年轻人,拜托下次回贴之前动动脑子,诋毁?我和VB有仇?定制control很难么?你认为有很多人不会么?
定制control一般用于控件,如果标准的控件能做到,一般不会去再造轮子。如果你是指定制control用于作为一个容器来规划GUI,那么它的成本太高,当你想把原先属于A group的控件放到B group将会很痛苦。如果定制control象MS Word里面对图形元素'group'和'ungroup'那么方便,那倒也不失为一个不错的方法。
相比而言在Ruby/GTK中,由于GUI元素在代码控制之下,加上duck typing,GUI元素的移动和再组合就非常方便。
有时候可视化的拖拖放放反而不如写代码容易...
你题目里所谓的复杂的界面,你慢慢用代码写出来,估计我都弄完了,你还在那里爬呢.
你的回复,只能说明你规划control的能力很弱.Control的代价远比单纯摆放UI元素要低,而且局部修改不影响大局.
如果有个程序员成天需要把A Control放到B Control里,那他就是个蹩脚货,或者是 写规划需求的人是个蹩脚货.
有利必有弊。有时候可视化的拖拖放放反而不如写代码容易。
年轻人,拜托下次回贴之前动动脑子,诋毁?我和VB有仇?定制control很难么?你认为有很多人不会么?
定制control一般用于控件,如果标准的控件能做到,一般不会去再造轮子。如果你是指定制control用于作为一个容器来规划GUI,那么它的成本太高,当你想把原先属于A group的控件放到B group将会很痛苦。如果定制control象MS Word里面对图形元素'group'和'ungroup'那么方便,那倒也不失为一个不错的方法。
相比而言在Ruby/GTK中,由于GUI元素在代码控制之下,加上duck typing,GUI元素的移动和再组合就非常方便。
由于Ruby/GTK不是用SWIG自动生成代码,所以迁移到1.9估计要一段时间,不过1.9的正式版不是还没有出来么~
最近手上的一个项目刚好需要做一个Windows平台的GUI程序,以前是用VB,虽然VB是Windows GUI的经典工具,能够快速进行GUI原型开发,但是一旦GUI元素多起来,且UI元素存在复杂关系,就很难维护....特别在后期,一旦需求有什么变化,再去调整UI,那个叫痛苦啊。因此就想用ruby试试,加上此次项目设计很多网络通讯方面的需求,因此更加坚定了使用ruby的决心。现在项目基本完工,再回过头看,以前用VB开发时碰到的种种问题在新项目中都被很好地解决了。特别地,体会到了Closure对于GUI编程的重要性。不管未来在的GUI编程领域ruby是否能成为主流,但是可以预见那种语言一定是具备Closure(或类似)功能的。(或者只是我的美好愿望?)
GUI库选型:
ruby发行包自带TK库,用于简单的程序还可以,但是一旦有复杂界面需求时就难以满足。目前比较成熟的GUI绑定库有RubyFox,wxRuby 和 RubyGnome. 鉴于GTK用的人比较多,加上GTK在Windows上的Runtime也是比较稳定,GTK应用的代表GIMP看起来也比较漂亮,因此就选择了RubyGnome作为GUI库。
关于RubyGnome我也不多介绍,其项目主页上的文档和教程非常不错。
Ruby-Gnome项目的首页: http://ruby-gnome2.sourceforge.jp/
1. Closure 作为响应GUI消息事件
在MFC中,响应消息通常需要定义OnXXX()虚函数,而且需要在消息传递宏里面与某个消息挂上勾,然后在实现OnXXX()函数。
在VB中,IDE为你为某个控件的消息生成消息响应函数。
那么在Ruby-Gnome里面,这么做:
button = Gtk::Button.new("Button A") button.signal_connect("clicked") do # ... when button clicked ... msgbox "Button clicked !" end
在这一点上,MFC最为繁琐不用说了。VB由IDE为你预先做了很多工作。ruby用代码关联“clicked”事件,用Closure作为消息响应,干净利落。
表面上看,似乎ruby的方式也未必好很多,但是且慢,看下一个....
2. Closure 里面可以访问当前上下文
GUI编程经常面临的一个头痛的问题是,UI元件通常需要是全局的,至少是窗口类内全局。例如,希望button被按下的时候改变label的内容,那么就要求在响应button事件的代码内要能够访问label。在MFC中,label被迫成为全局。在VB中,你不能控制。在界面元素很多的时候,这可能会成为一个问题--你不得不仔细地为每一个UI元件命名以防止名称冲突。
而在ruby中,由于Closure能够访问当前上下文,因此正好可以完美解决这个问题:
button = Gtk::Button.new("Button A") label = Gtk::Label.new("Hello") button.signal_connect("clicked") do label.text += "click " end
ruby的Closure使得代码“内聚”了,即相互关联的元素的作用域可以被限定在一个很小的范围,这样对于代码的维护和应付变化都是具有非凡的意义。
3. 动态打开一个类的能力使得扩展基类的功能变得简单
ruby能够动态地打开一个类并往里面增加method的能力已经不是什么新鲜事,对于这个特性也有很多争议。但对于GUI编程来说,这确实是提供了很大的方便。
在GUI编程中,msgbox是很常用的一个工具。在RubyGnome中,Gtk::Window没有msgbox这个接口,下面的例子就是封装了一个易用的Msgbox类,并打开Gtk::Window类,增加msgbox函数,这样所有基于Gtk::Window的类都可以随时调用msgbox:
require 'gtk2' =begin Msgbox: an easy message box based on Gtk::MessageDialog usage: example 1: Msgbox.new("This is a simple message box !").show example 2: if Msgbox.new("Yes or No ?", :type => :QUESTION, :buttons => :YES_NO).show puts "Your answer is: 'yes'" else puts "Your answer is not 'yes'" end example 3: Msgbox.new("OK or cancel ?", :type => :QUESTION, :buttons => :OK_CANCEL) do puts "Your answer: ok" end example 4, from within Gtk::Window or subclass: msgbox "Hello" msgbox! "warning infomation !" msgbox_err "error !" msgbox? "answer the question ...", :buttons=>:YES_NO =end class Msgbox def initialize(text = nil, param = {}, &block) @param = {} @param[:block] ||= block if @param[:block] show(text, param) else set_params(text, param) end end def set_params(text = nil, param = {}) @param[:parent] ||= param[:parent] @param[:text] ||= text @param[:buttons] = case param[:buttons] when :CANCEL, :cancel, "CANCEL", "cancel" Gtk::MessageDialog::BUTTONS_CANCEL when :CLOSE, :close, "CLOSE", "close" Gtk::MessageDialog::BUTTONS_CLOSE when :OK,:ok, "OK", "ok" Gtk::MessageDialog::BUTTONS_OK when :OK_CANCEL,:ok_cancel, "OK_CANCEL", "ok_cancel" Gtk::MessageDialog::BUTTONS_OK_CANCEL when :YES_NO, :yes_no, "YES_NO", "yes_no" Gtk::MessageDialog::BUTTONS_YES_NO when :NONE, :none, "NONE", "none" Gtk::MessageDialog::BUTTONS_NONE else @param[:buttons] || Gtk::MessageDialog::BUTTONS_OK end @param[:flags] ||= Gtk::Dialog::MODAL @param[:title] ||= param[:title] @param[:type] = case param[:type] when :ERROR @param[:title] ||= "Error" Gtk::MessageDialog::ERROR when :INFO @param[:title] ||= "Information" Gtk::MessageDialog::INFO when :QUESTION @param[:title] ||= "Question" Gtk::MessageDialog::QUESTION when :WARNING @param[:title] ||= "Warning" Gtk::MessageDialog::WARNING else @param[:title] ||= "Information" @param[:type] || Gtk::MessageDialog::INFO end end def show(text = nil, param = {}, &block) set_params(text, param) dialog = Gtk::MessageDialog.new(@param[:parent], @param[:flags], @param[:type], @param[:buttons], @param[:text]) dialog.title = @param[:title] dialog.signal_connect('response') do |w, response| @response = case response when Gtk::Dialog::RESPONSE_ACCEPT, Gtk::Dialog::RESPONSE_OK, Gtk::Dialog::RESPONSE_APPLY, Gtk::Dialog::RESPONSE_YES true else false end dialog.destroy end if @param[:parent] x, y = @param[:parent].position w, h = @param[:parent].size dw, dh = dialog.size dialog.move x + (w - dw) / 2, y + (h - dh) / 2 end dialog.run @param[:block] ||= block block.call if @param[:block] && @response @response end end class Gtk::Window def msgbox(text = nil, param = {}, &block) param[:parent] ||= self param[:block] ||= block Msgbox.new(text, param).show end def msgbox!(text = nil, param = {}, &block) msgbox(text, param.merge!({:type=>:WARNING, :block=>block})) end def msgbox_err(text = nil, param = {}, &block) msgbox(text, param.merge!({:type=>:ERROR, :block=>block})) end def msgbox?(text = nil, param = {}, &block) msgbox(text, param.merge!({:type=>:QUESTION, :block=>block})) end end if $0 == __FILE__ class TestWin < Gtk::Window def initialize super("Message Box Test") box = Gtk::HButtonBox.new buts = [] ["Info", "Warn", "Error", "Question"].each do |t| buts << (but = Gtk::Button.new(t)) box.pack_start but end buts[0].signal_connect("clicked") do msgbox "Hello" end buts[1].signal_connect("clicked") do msgbox! "Hello !" end buts[2].signal_connect("clicked") do msgbox_err "Hello, Hello, Hello !!", :title=>"Error happens !" end buts[3].signal_connect("clicked") do if msgbox? "Hello ?", :buttons=>:YES_NO msgbox "you select 'YES'" else msgbox "you don't select 'YES'" end end signal_connect("delete-event") do Gtk.main_quit false end add(box) end end win = TestWin.new win.show_all GC.start Gtk.main end
上面的例子来源于实际项目,为了使用方便做了很多封装,后面还有一段测试代码,所以有点长。如果你也用RubyGnome开发GUI,那么这个简易的Msgbox将会带来很多方便
Ruby作为GUI编程语言现在还不会成为主流,但是其动态特性将有助于解决传统GUI编程中遇到的问题,而且随着GUI binding lib的成熟,稳定,Ruby,有望在又一个领域成为编程利器。
评论
24 楼
sevk
2012-12-28
23 楼
xl19870805
2008-09-08
呵呵,看不懂英文的教程,哎,能力有限
22 楼
liusong1111
2008-09-06
ray_linn 写道
neodoxy 写道
看来语言障碍害死人啊
VB那只是一个ide的功劳吧了,ruby一样可以做一个ide,做一大堆可视化编辑
ruby的语言特性使得他用于gui编程是高效的,至少比vb是
你用vb码界面只代表ide代替你做了一些工作,而不是不需要做一些工作,别人自己写的ruby类库和代码生成器一样可以起到这个效果
VB那只是一个ide的功劳吧了,ruby一样可以做一个ide,做一大堆可视化编辑
ruby的语言特性使得他用于gui编程是高效的,至少比vb是
你用vb码界面只代表ide代替你做了一些工作,而不是不需要做一些工作,别人自己写的ruby类库和代码生成器一样可以起到这个效果
可以做,并不等于就有吧?C#的界面代码,已经帮你完成了80%以上的coding工作。
IDE所做的,是“设计阶段”的活。
手工写代码,建立在前者的基础上,做“运行阶段”的活,可以进行更灵活更复杂的控制和调整。
设计阶段的成果,用XML这样的标记语言存储比较好,最终作为代码执行起来。
ruby的closuer,使得它很接近标记语言,如果ui库设计的优良(比如前面提到的遵循CoC和Builder风格),IDE生成的东西和手写出来的代码应该接近一致。那么,它们的区别,更像是linux操作中,用shell还是GUI。
-- 差距减小。
我个人更喜欢GUI/IDE,因为属性、样式、事件列表可以直观看到,设置完关注的条目,还能直接看到效果。这就是IDE的威力吧。
不过,如果用IDE设计一个窗口时要设置一些东西,在做其它窗口时还要进行同样(或相似)的操作,就如同重复代码,是坏味道。代码通常用封装来消除重复,IDE操作呢?
1. 宏。如同代码生成器一样,生成起来简单 改起来难。
2. 组件封装。Flex对这方面支持的不错(.NET或许也不错吧,没研究过),可以组合其它组件,调整或定制属性、样式和事件,可以用MXML(IDE辅助)轻松完成,本质是类继承。新封装的组件能在IDE中使用。
把业务系统划分成一个个相对独立的界面部件,维护起来就爽了。VB一类的“老”式工具,对它支持不强。理想情况,我们在开发一个个“业务部件”,而不是界面。我们要表达的,只是这个部件应该提供的内容,而不是样式、技术控件之类的东西。
我觉得组件封装对人的要求比较高,要在把握业务的前提下,合理划分出组件、接口和交互关系。
识别重复操作的范围(偶然重复,局部重复,模块重复,全局重复),做出整体规划,都不是简单事。
如果以理想方式开发,由于尽可能的消除了IDE之上的重复操作,“设计阶段”的活减轻了,还有的转移成:用IDE+code开发“业务基础组件”。那么,对于逻辑简单的UI,整个开发工作量就比较小。逻辑复杂的UI,工作量转移到“运行阶段”也不足为奇。
-- 比重减小。
flex和.net都提供了data binding,相当于把一些通用UI控制逻辑也封装到了组件里,这种能力和模式,是把“本质不是运行阶段”的工作从“运行阶段”代码中提取出去。
组件的本质,殊途同归,仍然是代码级的类继承和抽象。让人充分利用IDE的同时,也需要人去理解代码和组件的映射关系。IDE的长处,是设定数据;代码的长处,是设定算法。DSL的好处,是降低两者的隔阂。(关于目前ruby DSL应用中,处理数据和算法上的问题,欢迎大家新开贴讨论)
“运行阶段”的重复,也同样需要处理。
组件的AOP,不知道有什么思路或现有方案?
21 楼
Howareyou73
2008-09-06
ROR用什么工具开发啊,是MyEclipse吗还是其他的,如果是MyEclipse 要导什么包啊
20 楼
ray_linn
2008-09-03
neodoxy 写道
看来语言障碍害死人啊
VB那只是一个ide的功劳吧了,ruby一样可以做一个ide,做一大堆可视化编辑
ruby的语言特性使得他用于gui编程是高效的,至少比vb是
你用vb码界面只代表ide代替你做了一些工作,而不是不需要做一些工作,别人自己写的ruby类库和代码生成器一样可以起到这个效果
VB那只是一个ide的功劳吧了,ruby一样可以做一个ide,做一大堆可视化编辑
ruby的语言特性使得他用于gui编程是高效的,至少比vb是
你用vb码界面只代表ide代替你做了一些工作,而不是不需要做一些工作,别人自己写的ruby类库和代码生成器一样可以起到这个效果
可以做,并不等于就有吧?C#的界面代码,已经帮你完成了80%以上的coding工作。
19 楼
neodoxy
2008-09-03
ray_linn 写道
neodoxy 写道
楼上是想说代码生成器比Ruby更高效么?
是VB这种语言更高效还是那个IDE比ruby更高效?IDE是语言本身么
是VB这种语言更高效还是那个IDE比ruby更高效?IDE是语言本身么
连在说什么都搞不清楚,就这里发言?
高效,当然是指开发效率,手工去堆砌界面能比IDE开发效率高? 楼主那个例子已经是简单的不能在简单了,在 GUI中根本不值一提,让他用手工写个outlook的界面看看,得花多少时间。
看来语言障碍害死人啊
VB那只是一个ide的功劳吧了,ruby一样可以做一个ide,做一大堆可视化编辑
ruby的语言特性使得他用于gui编程是高效的,至少比vb是
你用vb码界面只代表ide代替你做了一些工作,而不是不需要做一些工作,别人自己写的ruby类库和代码生成器一样可以起到这个效果
18 楼
rubynroll
2008-09-03
回到正题,Closure除了增强代码内聚之外,还容易使GUI进一步发展成Builder风格,例如 Cheri:http://cheri.rubyforge.org/
....嗯,其实应该这么说,在Builder风格下,Closure让代码内聚作用更加突出了。
Quake Wang推荐的Shoes也颇有Builder的风格。
....嗯,其实应该这么说,在Builder风格下,Closure让代码内聚作用更加突出了。
Quake Wang推荐的Shoes也颇有Builder的风格。
17 楼
rubynroll
2008-09-03
ray_linn 写道
俺以事实为依据写了一行C#完成他的狗屁FP.
这个很强!
ray_linn 写道
如果有个程序员成天需要把A Control放到B Control里,那他就是个蹩脚货,或者是 写规划需求的人是个蹩脚货.
还可以进一步的说,那些老变更需求的客户就是混蛋。
ray_linn 写道
...世界上绝大部分GUI,都是MFC的成果。
这个我是第一次听说,说来听听?
16 楼
Readonly
2008-09-03
ray_linn 写道
因为总有贴主说A vs B的时候总会有谬误,否则我怎么去抓他的小辫子。
比如最谬误的那个什么FP vs C# java, 俺以事实为依据写了一行C#完成他的狗屁FP.
比如最谬误的那个什么FP vs C# java, 俺以事实为依据写了一行C#完成他的狗屁FP.
大叔,偶觉得您参与搅和的这些A v.s B系列中,您颇有这篇帖子中“那人”的风采:
http://www.iteye.com/topic/235214
15 楼
ray_linn
2008-09-03
Readonly 写道
JavaEye论坛规律第8条:
每当ray_linn开始讨论A v.s B类型的技术问题时,大家可以忽略他的言论。
每当ray_linn开始讨论A v.s B类型的技术问题时,大家可以忽略他的言论。
因为总有贴主说A vs B的时候总会有谬误,否则我怎么去抓他的小辫子。
比如最谬误的那个什么FP vs C# java, 俺以事实为依据写了一行C#完成他的狗屁FP.
14 楼
Readonly
2008-09-03
JavaEye论坛规律第8条:
每当ray_linn开始讨论A v.s B类型的技术问题时,大家可以忽略他的言论。
每当ray_linn开始讨论A v.s B类型的技术问题时,大家可以忽略他的言论。
13 楼
ray_linn
2008-09-03
rubynroll 写道
ray_linn 写道
高效,当然是指开发效率,手工去堆砌界面能比IDE开发效率高? 楼主那个例子已经是简单的不能在简单了,在 GUI中根本不值一提,让他用手工写个outlook的界面看看,得花多少时间。
开发软件不是光是弄个界面摆在那儿。单论界面生成,用代码当然比不上可视化IDE快。但是当界面具有复杂GUI元素,并且需要与复杂程序逻辑粘合,用代码生成界面具有更大的灵活性,比如方便动态添加/移除GUI元素,容易调整GUI结构。
其实Ruby/GTK也可以用Glade来可视化编辑界面,在实际的工程中,我一般是用Glade生成那些普通的用于展现数据的界面,而对于有复杂逻辑的,存在大量动态变化的界面,还是用代码更方便。
可视化界面编辑器可以降低GUI开发门槛,加速简单GUI界面开发。但是对于整个程序开发来说,设计良好的GUI库,语言的表达能力和某些特性(例如本文所讨论的Closure),比“拖拖拉拉”的快感更重要。
任何复杂的GUI都是由若干简单的element构成的,基本算的上掌握GUI的能力,就是应该能把element复合成一定功能control以期组合成更复杂的gui. 拖拖拉拉,不过是你对GUI最粗浅的认识而已。
所谓手工代码具备更大灵活性,完全就是个伪命题,当UI元素蜕化成XML(XUL,WPF),不再以所谓的代码耦合的时候,UI还是UI. 世界上绝大部分GUI,都是MFC的成果。
12 楼
rubynroll
2008-09-03
ray_linn 写道
高效,当然是指开发效率,手工去堆砌界面能比IDE开发效率高? 楼主那个例子已经是简单的不能在简单了,在 GUI中根本不值一提,让他用手工写个outlook的界面看看,得花多少时间。
开发软件不是光是弄个界面摆在那儿。单论界面生成,用代码当然比不上可视化IDE快。但是当界面具有复杂GUI元素,并且需要与复杂程序逻辑粘合,用代码生成界面具有更大的灵活性,比如方便动态添加/移除GUI元素,容易调整GUI结构。
其实Ruby/GTK也可以用Glade来可视化编辑界面,在实际的工程中,我一般是用Glade生成那些普通的用于展现数据的界面,而对于有复杂逻辑的,存在大量动态变化的界面,还是用代码更方便。
可视化界面编辑器可以降低GUI开发门槛,加速简单GUI界面开发。但是对于整个程序开发来说,设计良好的GUI库,语言的表达能力和某些特性(例如本文所讨论的Closure),比“拖拖拉拉”的快感更重要。
11 楼
ray_linn
2008-09-03
neodoxy 写道
楼上是想说代码生成器比Ruby更高效么?
是VB这种语言更高效还是那个IDE比ruby更高效?IDE是语言本身么
是VB这种语言更高效还是那个IDE比ruby更高效?IDE是语言本身么
连在说什么都搞不清楚,就这里发言?
高效,当然是指开发效率,手工去堆砌界面能比IDE开发效率高? 楼主那个例子已经是简单的不能在简单了,在 GUI中根本不值一提,让他用手工写个outlook的界面看看,得花多少时间。
10 楼
neodoxy
2008-09-02
楼上是想说代码生成器比Ruby更高效么?
是VB这种语言更高效还是那个IDE比ruby更高效?IDE是语言本身么
是VB这种语言更高效还是那个IDE比ruby更高效?IDE是语言本身么
9 楼
ray_linn
2008-09-02
rubynroll 写道
ray_linn 写道
这个帖子颇有意淫的感觉,在VB里写个界面需要你动手写一行代码吗?
有利必有弊。有时候可视化的拖拖放放反而不如写代码容易。
ray_linn 写道
但是一旦GUI元素多起来,且UI元素存在复杂关系,就很难维护 --- 这是明显的诋毁,或者是自己水平太臭,难道一个复杂的UI,不懂得定制control吗?
年轻人,拜托下次回贴之前动动脑子,诋毁?我和VB有仇?定制control很难么?你认为有很多人不会么?
定制control一般用于控件,如果标准的控件能做到,一般不会去再造轮子。如果你是指定制control用于作为一个容器来规划GUI,那么它的成本太高,当你想把原先属于A group的控件放到B group将会很痛苦。如果定制control象MS Word里面对图形元素'group'和'ungroup'那么方便,那倒也不失为一个不错的方法。
相比而言在Ruby/GTK中,由于GUI元素在代码控制之下,加上duck typing,GUI元素的移动和再组合就非常方便。
有时候可视化的拖拖放放反而不如写代码容易...
你题目里所谓的复杂的界面,你慢慢用代码写出来,估计我都弄完了,你还在那里爬呢.
你的回复,只能说明你规划control的能力很弱.Control的代价远比单纯摆放UI元素要低,而且局部修改不影响大局.
如果有个程序员成天需要把A Control放到B Control里,那他就是个蹩脚货,或者是 写规划需求的人是个蹩脚货.
8 楼
rubynroll
2008-09-01
ray_linn 写道
这个帖子颇有意淫的感觉,在VB里写个界面需要你动手写一行代码吗?
有利必有弊。有时候可视化的拖拖放放反而不如写代码容易。
ray_linn 写道
但是一旦GUI元素多起来,且UI元素存在复杂关系,就很难维护 --- 这是明显的诋毁,或者是自己水平太臭,难道一个复杂的UI,不懂得定制control吗?
年轻人,拜托下次回贴之前动动脑子,诋毁?我和VB有仇?定制control很难么?你认为有很多人不会么?
定制control一般用于控件,如果标准的控件能做到,一般不会去再造轮子。如果你是指定制control用于作为一个容器来规划GUI,那么它的成本太高,当你想把原先属于A group的控件放到B group将会很痛苦。如果定制control象MS Word里面对图形元素'group'和'ungroup'那么方便,那倒也不失为一个不错的方法。
相比而言在Ruby/GTK中,由于GUI元素在代码控制之下,加上duck typing,GUI元素的移动和再组合就非常方便。
7 楼
ray_linn
2008-09-01
这个帖子颇有意淫的感觉,在VB里写个界面需要你动手写一行代码吗?
但是一旦GUI元素多起来,且UI元素存在复杂关系,就很难维护 --- 这是明显的诋毁,或者是自己水平太臭,难道一个复杂的UI,不懂得定制control吗?
但是一旦GUI元素多起来,且UI元素存在复杂关系,就很难维护 --- 这是明显的诋毁,或者是自己水平太臭,难道一个复杂的UI,不懂得定制control吗?
6 楼
QuakeWang
2008-08-31
借助Ruby闭包,GUI编程确实可以变得很简洁。
顺这个帖子推荐一下Shoes,一个基于Ruby的小巧GUI工具包:
http://code.whytheluckystiff.net/shoes/
可运行在windows/macos/ubuntu(gtk)下面,http://the-shoebox.org/是Shoes应用的集中地。
我们可以看到一个经典的扫雷游戏只用270行ruby代码就可以搞定,这270行包括用代码"画"地雷/旗子/数字等等,可以和Java来对比看实现需要多少行:
http://the-shoebox.org/apps/36
顺这个帖子推荐一下Shoes,一个基于Ruby的小巧GUI工具包:
http://code.whytheluckystiff.net/shoes/
可运行在windows/macos/ubuntu(gtk)下面,http://the-shoebox.org/是Shoes应用的集中地。
我们可以看到一个经典的扫雷游戏只用270行ruby代码就可以搞定,这270行包括用代码"画"地雷/旗子/数字等等,可以和Java来对比看实现需要多少行:
http://the-shoebox.org/apps/36
5 楼
rubynroll
2008-08-31
wxz125627771 写道
Gtk库在ruby 1.9.0下部能用了 。。怎么办?
由于Ruby/GTK不是用SWIG自动生成代码,所以迁移到1.9估计要一段时间,不过1.9的正式版不是还没有出来么~
发表评论
-
vi tips
2010-07-20 11:37 0These tips are just memo for my ... -
Setup PPTP VPN on ubuntu 9.10
2009-12-20 19:27 1853Something should be done to set ... -
交叉编译完全解决方案
2009-09-18 09:55 3685[注:本文仅适用于嵌 ... -
OpenCV+Ruby构建图像处理研究平台
2009-09-12 15:31 3040OpenCV OpenCV是一个很流行 ... -
Maemo下跑RubyGnome2
2009-09-09 20:07 2270稍微捣鼓了一下,RubyGnome2顺利在Maemo模拟器上运 ... -
GtkSimpleLayout Inspector
2009-09-06 20:01 1650Inspector介绍 Inspector是GtkSimple ... -
300行代码你能做什么
2009-09-02 14:12 4256我也标题党一回:300行 ... -
FAT over NAND Flash
2009-04-27 21:03 10697引子 最近有一个项目需要在NAND FLASH裸片上建立文件 ... -
UFFS嵌入式NAND FLASH文件系统 FAQ(1)
2009-04-15 19:03 0自从UFFS项目放到SF上, 陆陆续续收到不少邮件询问有关的问 ... -
Tips: 为源代码树打一个干净的包
2009-04-02 13:19 1913为源代码树打一个干净的包 ------------- ... -
Linux tips: allow more than 4 serial ports
2009-02-12 12:58 3819搞嵌入式的经常要和串口通讯打交道,在开发的时候有可能同时使用十 ... -
交叉编译Ruby傻瓜指南
2009-02-05 11:35 2784最近看到有人在交叉编译ruby的时候似乎碰到了许多问题(htt ... -
优化Debian/Ubuntu下的ruby
2008-12-30 19:27 2093我们都知道Debian/Ubuntu通过apt-get安装的r ... -
Debian/Ubuntu Tips: find the right package
2008-12-12 17:35 1107Debian/ubuntu下经常碰到需要安装某个程序,却一时想 ... -
Ruby/GTK应用笔记(3):垃圾回收
2008-09-14 08:39 2610虽然垃圾回收应该属于RubyVM自动处理的事,但是一旦涉及到C ... -
Ruby/GTK应用笔记(2): Gdk::Pixbuf
2008-09-01 17:08 3741Gdk::Pixbuf是GTK库极为重 ... -
Ruby/GTK应用笔记(1): Gtk::Toolbar
2008-08-21 13:04 1971由于Gtk的Toolbar内部接口发生了一些变化,在使用Gtk ... -
Ruby/Rails: 不一样的'Web'应用(续)
2008-07-28 21:23 1300上一篇文章(http://www.itey ... -
Ruby/Rails: 不一样的'Web'应用
2008-07-26 15:45 1461我不是Web程序员,也从 ... -
一个有趣的问题: 如何获取引用名?
2008-07-24 17:26 1360我们知道, 对于 a = 100 这样的一条语句, a是一 ...
相关推荐
Ruby是一种常用于Web开发的解释型面向对象编程语言。 它还提供了许多脚本功能来处理纯文本和序列化文件,或管理系统任务。 它是简单,直接和可扩展的。 Ruby的功能 简单语法 普通的面向对象功能(例如,类,方法...
### Ruby编程语言简介 #### 一、Ruby语言的起源与发展 Ruby是一种简洁高效的面向对象脚本语言,由日本人松本行弘(Yukihiro Matsumoto)在20世纪90年代开发。作为一种相对年轻的编程语言,Ruby的设计理念融合了...
Ruby元编程是编程领域中一个深入且强大的主题,它允许程序员在运行时修改或创建代码,极大地提高了灵活性和代码的动态性。这本书“Ruby元编程第二版”专注于讲解Ruby语言的这一独特特性,旨在帮助开发者更好地理解和...
### 前端学 Ruby:熟悉 Ruby 语法 #### Ruby 是什么? Ruby 是一种动态的、面向对象的脚本语言,由日本人松本行弘在 1995 年设计并开发。作为一种解释型语言,Ruby 具有简单易懂、功能强大且灵活的特点。Ruby 在 ...
内容概要:本文是一份全面的Ruby编程教程,涵盖了从基础入门到高级特性的所有内容。文章首先介绍了Ruby语言的特点和优势,接着详细讲解了环境搭建、基本语法、面向对象编程等内容。随后,通过几个实用的项目案例(如...
Ruby元编程是Ruby编程语言中的一个重要特色,它指的是Ruby语言允许程序员在运行时对类、方法和变量等进行操作的能力。通过元编程,开发者可以编写出更加简洁、灵活和高效的代码。《Metaprogramming Ruby》这本书深入...
本书不仅涵盖了Ruby编程的基础知识,还深入探讨了高级主题,使得读者能够在实践过程中掌握Ruby的核心概念和技术。 ### 一、Ruby语言概述 #### 1.1 什么是Ruby Ruby是一种简洁、高效、面向对象的脚本语言,由日本人...
Ruby是一种常用于Web开发的解释型面向对象编程语言。 它还提供了许多脚本功能来处理纯文本和序列化文件,或管理系统任务。 它是简单,直接和可扩展的。 Ruby的功能 简单语法 普通的面向对象功能(例如,类,方法调用...
系统需求Ruby版本大于等于2.0.0。因为前后端通讯使用了websocket,所以需要使用支持websocket的浏览器。目前打开文件对话框只实现了windows版本,在Linux等使用会出错,以后会尝试在其他系统实现,除此之外对系统...
对于初学者,可以从以下几个方面入手学习Ruby: 1. 学习基础语法:了解变量、常量、运算符、控制结构(条件语句、循环)、函数、类和模块的使用。 2. 掌握面向对象:理解类和对象的关系,继承、封装和多态的概念。...
内容概要:全面掌握Ruby编程语言,轻松应对各种开发挑战! 适用人群:适合对编程感兴趣的初学者,以及希望快速入门Ruby语言的开发者。 使用场景及目标:通过幽默风趣的语言和生动的比喻,帮助读者理解并掌握Ruby编程...
根据提供的文件信息,本文将对《Ruby元编程》这一主题进行深入探讨,解析其核心概念、应用场景以及为何元编程在Ruby语言中具有重要的地位。 ### 一、Ruby元编程简介 #### 1.1 元编程定义 元编程是指编写能够生成或...
在Ruby编程语言中,元编程是一种强大的特性,它允许我们在运行时动态地创建、修改甚至执行代码。"tadp-2015c1-metaprogramacion-xunit-ruby"是一个关于元编程和XUnit测试框架在Ruby中的应用的练习项目。元编程在软件...
在Ruby中使用块:一份脑友好的报告(Jay McGavren)是一本专注于Ruby编程语言中块(block)概念的图书。Ruby块是一种类似闭包的结构,可以在Ruby的方法调用中传递代码块,以此来处理不同的任务。本书的目标是帮助...
Ruby元编程是编程的一种高级技巧,它允许程序员在运行时动态地修改或创建代码,极大地提高了灵活性和代码的可扩展性。Ruby作为一种动态类型语言,其元编程能力尤为强大,使得开发者可以创建出高度定制化的解决方案。...
【RubyGnome2库】是Ruby语言用于GTK+图形用户界面开发的重要工具,它为GTK+库提供了完整的Ruby封装,允许开发者用Ruby语言编写GUI应用程序。RubyGnome2保留了GTK+的API命名规则,使得熟悉GTK+的开发者能够轻松过渡到...
Ruby编程语言入门与实践 Ruby编程语言入门与实践 Ruby编程语言入门与实践 Ruby编程语言入门与实践 Ruby编程语言入门与实践 Ruby编程语言入门与实践 Ruby编程语言入门与实践 Ruby编程语言入门与实践 Ruby编程语言入门...
《Ruby编程,实用程序员指南》是一本针对Ruby语言的学习教程与参考手册,旨在为程序员提供一个全面、深入的Ruby语言学习资源。本书不仅适合初学者快速入门,也适合具有一定经验的开发者进阶学习。 ### 一、Ruby语言...