meruby / gmail.com wrote:

> Hal,
>   Most of the gui toolkit in dynamic language has its origin in C or
> C++. Because of its origin, its api are more static and less dynamic
> (less pythonic or rubyish).
>   In python world, wxPython is an interface written on top of wxgtk
> (C++). To make it more dynamic and pythonic api, wax (other one is
> pythoncard) is written on top of it.
> Visit http://zephyrfalcon.org/labs/dope_on_wax.html  "Wax is a GUI
> toolkit. It sits on top of wxPython, removing some of the low-level
> aspects of that GUI, and adding some useful abstractions." Google
> summer of code allow not one but two coders to work on wax to make it
> better and improve documentation
> http://zephyrfalcon.org/labs/wax_summer_of_code.html
I've just been reading about wax, and it seems to be about addressing the
problems that wxPython has being directly based on the wxWidgets api.

Quote from the wax docs: 

"1. It's no longer necessary to make up IDs and pass them around. You just
create an object like you would expect:

b = Button(parent, "click me")

.... "

With QtRuby you don't need to 'make up IDs and pass them around', and you
create a button much as in the above code.

> Now sad part: I have some knowledge on qtruby and very little on Qt. I
> haven't program in C or C++ for ages. In a way its blessing, since I
> love to work in dynamic language, I can't stand working in static
> language like C, C++, C#, Java and such. I can not give you specific
> example about what I want to do with qtruby, because I have never
> created any big program. My vision is to make qtruby easy enough that
> end user don't have to think about another api for guil; if they know
> ruby, they should be able to use qtruby without spending days to learn
> its api.
I certainly think QtRuby could be made easier to use. Possibly by
automatically translating the C++ documentation to ruby and RDOC format if
that was possible. Probably the ugliest and least ruby-like thing are
signals and slots, as they have C++ type signatures as strings. The way you
connect a signal to a block in ruby-gnome is nicer, and I would rather have
QtRuby work more like that.

There are already quite a few things that you can do in QtRuby that you
couldn't do in the original C++ api. Such as passing blocks to
constructors, using lower case/underscore method naming if preferred, or
setFoobar() methods can be called as foobar= in ruby and isFoobar() methods
called as foobar?.

-- Richard