claird / starbase.neosoft.com wrote:
>In article <0G6900C8DCEARR / mta5.snfc21.pbi.net>,
>Kevin Smith  <sent / qualitycode.com> wrote:
>			.
>			.
>			.
>>- GTK parameters are all "normal" instead of the 
>>confusing hashes and blocks used by Perl/Tk. 
>>Also, Tk wants parameters as strings, like 'end', 
>>which I didn't like.
>I'm a bit lost on these remarks.  My
>impression is that Perl/Tk observes
>good Perl style, as most of its users
>prefer.  Ruby/Tk needn't repeat its
>choices of parameter bindings.

Probably so. The Ruby/Tk bindings are 
intentionally similar to Perl/Tk. This has the 
advantage of allowing you to use Perl/Tk docs. 
But the interface isn't very pleasant in Ruby.

>
>What do you prefer to "end"?  A type
>other than string, or a different
>value, or ...?

GTK often uses -1 to mean "end", which I like. 
Ruby/Tk uses the string 'end', which is obviously 
harder to type.

>>- GTK packing seems much more straightforward.
>Geometry management has long been one
>of Tk's acknowledged strengths.  What's
>a specific example of a GTK+ superiority
>in this regard?

Probably mostly due to the bindings. Having to 
say things like:
scroll_bar.pack('side' => 'left', 'fill' => 'y')
is pretty unpleasant. With GTK, you establish 
your fill by passing true or false, and determine 
the side using container.pack_start(xxx) or 
container.pack_end(xxx), at least for an hbox or 
vbox. I have not done fancy packing in GTK. 
Simple packing is easier in Ruby/GTK than in 
Ruby/Tk.

So, in summary:
- Ruby/Tk bindings are not very friendly or Ruby-
like
- GTK is a closer fit with my personal 
preferences and past experiences

Kevin