Ruby: GUI编程的利器

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里面，这么做：

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类库和代码生成器一样可以起到这个效果

可以做，并不等于就有吧？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类库和代码生成器一样可以起到这个效果

可以做，并不等于就有吧？C#的界面代码，已经帮你完成了80%以上的coding工作。

19 楼 neodoxy 2008-09-03  

ray_linn 写道

neodoxy 写道

楼上是想说代码生成器比Ruby更高效么?
是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的风格。

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.

大叔，偶觉得您参与搅和的这些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类型的技术问题时，大家可以忽略他的言论。

因为总有贴主说A vs B的时候总会有谬误，否则我怎么去抓他的小辫子。

比如最谬误的那个什么FP vs C# java, 俺以事实为依据写了一行C#完成他的狗屁FP.

14 楼 Readonly 2008-09-03  

JavaEye论坛规律第8条：
每当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是语言本身么

连在说什么都搞不清楚，就这里发言？

高效，当然是指开发效率，手工去堆砌界面能比IDE开发效率高？ 楼主那个例子已经是简单的不能在简单了，在 GUI中根本不值一提，让他用手工写个outlook的界面看看，得花多少时间。

10 楼 neodoxy 2008-09-02  

楼上是想说代码生成器比Ruby更高效么?
是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吗？

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

5 楼 rubynroll 2008-08-31  

wxz125627771 写道

Gtk库在ruby 1.9.0下部能用了 。。怎么办？

由于Ruby/GTK不是用SWIG自动生成代码，所以迁移到1.9估计要一段时间，不过1.9的正式版不是还没有出来么～