Andy Maleh

Thank you for showcasing my Ruby gems. To answer the first thing you wondered about, the reason Glimmer provides a DSL for so many GUI toolkits is because it assumes a pragmatic software engineering stance of acknowledging that no GUI toolkit is perfect and there are trade-offs to choosing each GUI toolkit over another, but nobody wants to write C or Java code in Ruby, so Glimmer offers a sane Ruby-friendly DSL for each GUI toolkit that does things the Ruby way (e.g. convention over configuration) while balancing that out by keeping some conventions from each GUI toolkit's makers so that their users find welcoming. Regarding Glimmer DSL for Tk, Tk works just fine on the Mac. Mac is my main personal platform that I develop Glimmer DSL for Tk on all the time. You simply did not follow the instructions that are on the project page, specifically "Follow the install instructions", which take you to the Tk tutorial page install instructions. A little below that, you will see an example of what to do on the Mac, specifically: Install the ActiveTcl Mac package from ActiveState.com Install Ruby via RVM for Tk: rvm install 3.0.2 --enable-shared --enable-pthread --with-tk --with-tcl Finally, install the tk gem separately or as part of glimmer-dsl-tk Regarding Glimmer DSL for LibUI, keep in mind that the project is two-months old only and is progressing very fast day-by-day (reporting issues will only make it progress faster, so please report any issues you encounter). Here is how your sample button inc/dec application is written (note that Glimmer DSL for SWT bidirectional/unidirectional data-binding features are making it into Glimmer DSL for LibUI as we speak to simplify the code further): require 'glimmer-dsl-libui' class CounterApp include Glimmer attr_accessor :count def initialize @count = 0 observer = Glimmer::DataBinding::Observer.proc { @label.text = "Count: #{@count}" } observer.observe(self, :count) end def launch window('Hello, Button!') { margined true vertical_box { @label = label('Count: ') { stretchy false } horizontal_box { stretchy false button('+1') { on_clicked { self.count += 1 } } button('-1') { on_clicked { self.count -= 1 } } } } }.show end end CounterApp.new.launch As for libui's refusal to activate on the Mac, that is normal behavior explained here. Regarding the last example you wrote in Glimmer DSL for SWT, there are two things to note: 1 - You do not need to supply -J-XstartOnFirstThread yourself since you are supposed to follow the gem post install instructions, which clearly state that on the Mac, you must run glimmer-setup and it will configure all Mac required options for you globally (e.g. -J-XstartOnFirstThread ). Afterwards, you simply run applications with glimmer command though ruby works just as well. Example: andymaleh@Andys-MacBook-Pro-13 glimmer-dsl-swt % gem install glimmer-dsl-swt Fetching glimmer-dsl-swt-4.21.2.3.gem You are ready to use `glimmer` and `girb` commands on Windows and Linux. On the Mac, run `glimmer-setup` command to complete setup of Glimmer DSL for SWT, making `glimmer` and `girb` commands ready for use: glimmer-setup Successfully installed glimmer-dsl-swt-4.21.2.3 1 gem installed andymaleh@Andys-MacBook-Pro-13 glimmer-dsl-swt % 2 - you are missing a layout option (just as one would in CSS too). You must tell it to have the label fill the width by adding one very simple option (add fill true inside row_layout): require 'glimmer-dsl-swt' class CounterApp include Glimmer::UI::CustomShell attr_accessor :count before_body do @count = 0 end body { shell { text "Hello, Button!" row_layout(:vertical) { fill true } label { text <= [self, :count, on_read: lambda{|v| "Count: #{v}" }] } group { row_layout :horizontal button { text "+1" on_widget_selected { self.count += 1 } } button { text "-1" on_widget_selected { self.count -= 1 } } } } } end CounterApp.launch As a final note regarding Glimmer DSL for Opal (which relies on Glimmer DSL for XML & HTML behind the scenes), note that it would be great to support Ruby in the long run if you consider yourself a Rubyist at all since Ruby has the best "potential" solution even if the libraries are not fully developed yet. People spend too much time focusing on the "actual" and miss out on how much "potential" Ruby has in simplifying our lives since it is one language that can handle both structure with DSLs and logic with English-like syntax, so all the complexity of having to rely on multiple different languages and mixing them together goes away. It would be much more productive to support Ruby approaches in the long term than getting used to complexity like a frog being slowly boiled. If a problem is not solved today, then great! That's where we focus next to come up with a better Ruby way, which would most certainly be better than all actual non-Ruby ways. Just my 2 cents.