The definitive GUI for Ruby

[Jeff Hobbs]

Tk is still too ugly for make programmers that are
migrating.

Tk is only ugly if that's the way you like it. You have a
full set of themed widgets available now that give you
native look and feel, with all the same dynamic control and
general ease of use that Tk has always provided. All this
on Aqua, Win32 and X11 (even Windows/CE). Some screenshots
of Tk apps that try not to be ugly:

The Perl Dev Kit and Tcl Dev Kit UIs:
http://aspn.activestate.com/ASPN/do...lapp_gui_configuring_perlapp_build_parameters
http://aspn.activestate.com/ASPN/docs/Tcl_Dev_Kit/3.2/TclVFSE.html

Tk on Win/CE (I know that the Perl/Tcl::Tk use this too):
http://wiki.tcl.tk/8442

Coccinella:
http://hem.fyristorg.com/matben/
http://hem.fyristorg.com/matben/examples/index.html

An installer builder:
http://installbase.sourceforge.net/screenshots.shtml

An example of improving a Tk app by "going native":
http://wiki.tcl.tk/14522

 

[Eustaquio Rangel de Oliveira J]

Eustaquio Rangel de Oliveira J wrote:
Tk is only ugly if that's the way you like it. You
have a
full set of themed widgets available now that give
you
native look and feel, with all the same dynamic
control and
general ease of use that Tk has always provided.=20
All this
on Aqua, Win32 and X11 (even Windows/CE). Some
screenshots
of Tk apps that try not to be ugly:

An example of improving a Tk app by "going native":
http://wiki.tcl.tk/14522

Oh boy, was me that did not checked all its features
or Tk has evolved a lot on the last years? Will take a
look on all that stuff.

Thanks a lot for the links, Jeff. I hope you didn't
get the "ugly" thing as an insult.=20

Best regards,

 

[Jeff Hobbs]

Oh boy, was me that did not checked all its features
or Tk has evolved a lot on the last years? Will take a
look on all that stuff.

Thanks a lot for the links, Jeff. I hope you didn't
get the "ugly" thing as an insult.

No insult taken. Tk certainly keeps moving, but it's done in
a low-key manner. There have always been many extensions to
Tk that provide a wealth of extra functionality. User demand
for the native widget extension (tile) has triggered its
inclusion for Tk 8.5 (still in development). Looking at the
Ruby/Tk sources, there appears to be support for tile in there
already (based on the Tk 8.4 stuff).

The classic Tk widgets do have a dated look, but even that is
easily modified with a few lines of code and the 'option'
command. For true native look and feel though, you really
need to rearchitect the widgets (as tile/ttk does). For
example, most tile widgets don't have a -background option -
that is something that the theme controls (and when you are on
something like OS X, may not be a simple color at all).

Anyways, Tk may still not be the ideal toolkit for your needs,
but "because it's ugly" is no longer a valid reason.

 

[Rich Morin]

I haven't seen any mention of Rails in this discussion. It seems
to me that RubyCocoa, Ruby/Tk, and other GUI APIs might benefit
from being set up as Rails "views".

-r

 

[Jim Freeze]

You may be interested to know about

RubyCocoa - A Ruby/Objective-C Bridge for Mac OS X with Cocoa
http://rubycocoa.sourceforge.net/doc

* Objective-C has its own naming conventions and method invocation
syntax, which are quite different from those used by Ruby, Python,
etc. In CamelBones, this means that the programmer has to look up
methods by "translated" names, etc.

From my limited experience, there is a straightforward pattern to
follow to convert from OC to Ruby. For example, from the tutorial:

[oPanel runModalForDirectory:self file:nil types nil]

becomes

oPanel.runModalForDirectory_file_types(self, nil, nil)


"The other technique can be used to make a little more sense of method
names that are extremely long. Using this technique, the method name
consists of everything in the Objective-C method's name up to the
first detached parameter name. The rest of the parameter names are
moved into the argument list. Thus, every argument after the first is
prefaced with another argument that is a Ruby symbol with the same
name as the parameter it represents. It sounds confusing, I know, but
the example below shows you how easy it is once you get used to the
syntax."

And, when standard calls return an NSArray or NSString, just use
#to_a and #to_s to convert them to ruby.

 

[Eustaquio Rangel de Oliveira J]

Anyways, Tk may still not be the ideal toolkit for
your needs,
but "because it's ugly" is no longer a valid reason.

Sure.

Best regards,

 

[Dave Baldwin]

You may be interested to know about

RubyCocoa - A Ruby/Objective-C Bridge for Mac OS X with Cocoa
http://rubycocoa.sourceforge.net/doc

* Objective-C has its own naming conventions and method
invocation
syntax, which are quite different from those used by Ruby,
Python,
etc. In CamelBones, this means that the programmer has to
look up
methods by "translated" names, etc.

From my limited experience, there is a straightforward pattern to
follow to convert from OC to Ruby. For example, from the tutorial:

[oPanel runModalForDirectory:self file:nil types nil]

becomes

oPanel.runModalForDirectory_file_types(self, nil, nil)

Or alternatively:
oPanel.runModalForDirectory(self, :file, nil :types, nil]

which I think is often clearer and preserves the parameter type
(recorded as a symbol) by the actual parameter.

My limited experience has been that RubyCocoa is very easy to use and
there isn't much to learn to map between the ruby and objective c
domains. Getting to grips with Cocoa is much harder but at least
with RubyCocoa all the memory management headaches go away.

Dave.

 

[Dave Howell]

Well, actually, you use non-Aqua GUIs all the time.

But my definition of "application" doesn't include web sites. Yours
might.

You may be interested to know about

RubyCocoa - A Ruby/Objective-C Bridge for Mac OS X with Cocoa

Actually, I've been using RubyCocoa for some months.

My experience with CamelBones (which does the same sort of thing for
Perl) leads me to suspect that the experience is not seamless:

* Objective-C has its own naming conventions and method invocation
syntax, which are quite different from those used by Ruby, Python,
etc. In CamelBones, this means that the programmer has to look up
methods by "translated" names, etc.

The developer came up with two different methods for mapping. I only
learned one of them, because it's so easy.

To grab a random sample out of "Cocoa Programming for Mac OSX"
- (void)drawAtPointNSPoint)aPoint
withAttributesNSDictionary *)attribs

should appear in Ruby as

def drawAtPoint_withAttributes(aPoint, attribs)
blah blah blah
end

Interface Builder will 'magically' fill in ObjC skeletons for you in
XCode, but you have to do that yourself in Ruby. Since that basically
means that you don't get

def YourObjectNameHere(something)
end

typed for you, I really don't think that's too much of a loss. I am
occasionally tripped up when I don't get a Cocoa object turned back
into a Ruby one, but that's because it's _almost_ always handled by
RubyCocoa.

RubyCocoa's still chasing some of the more recent and esoteric
features. "Bindings" are not entirely smooth, and "Core Data" (from
Tiger) depends on Bindings. But my background has been using XCode with
AppleScript, and Ruby and RubyCocoa are doing much better than the
AppleScript Studio support from Apple.

RubyCocoa does teach XCode do to syntactic coloring and procedural
bookmarking and other stuff. Overall, I like it.

I would be happy to hear comments from any RubyCocoa users, as I've
been
considering trying it out at some point...

Try (e-mail address removed). They're very nice and
helpful, even when I've been rather grumpy and cross from being
tortured by the installers for Ruby, RubyCocoa, Rails, RubyAEOSA, and
RubyGems. I don't think I"ve ever had a Ruby[whatever] install itself
smoothly the first time, with the single exception of whoever created
the Ruby 1.8.2 installer that uses the Mac's own installation system.
That, thank the stars, actually worked right the first time.