[ruby-talk:8226] Re: GUIs for Rubies

Cameron Laird wrote:
 
# Dave Thomas  <[e-mail]> wrote:
# >"Conrad Schneiker" <[e-mail]> writes:
# >
# >> Let me more or less repeat my earlier question, this time to Dave 
# >> (Thomas): what was your reason for telling the XP folks that Ruby 
# >> (presumably with Tk) was not up to snuff for heavy GUI lifting? 
# >> Performance? Missing many now-common-elsewhere widgets? Or ...?
# >
# >Because GUI work implies stuff in the client domain. For developers,
# >they'll be comparing Ruby to drag-n-drop code builders (Visual Age,
# >JBuilder, etc). They'll be look for business objects, tables that link 
# >automatically to database queries, and so on and so on. 
# >
# >You _could_ craft a client application in Ruby today, but you'd be
# >doing it without much environmental support, and with no convenient
# >end-user deployment mechanism.
# >
# >Clearly you can do serious work with Tk: SourceNavigator looks great
# >and is a Tk application. but it ain't easy, and I think we'd get
# >ridiculed if we help Ruby up as a client-side application builder to
# >the average Java or VB programmer.
 
# I've seen a few of my comments repeated.  Warning:  I
# neglect the motivations of the developers Mr. Thomas
# correctly describes here.  He's absolutely right:  all
# our nattering about FOX, GTK+, and so on, is pointless
# to them, 'cause there's no drag-and-drop database
# query thingie. 
# 
# That doesn't distinguish Tk, though, does it?  Tk (with
# VTk, SpecTcl, ...) is just as close to having a competi-
# tive builder (in this sense) as wxWindows, FOX, ...,
# right?

Good question. IMHO, the answer is, kinda yes, but also sorta no. 

For one thing, what you want is something that generates Ruby/Tk, not 
Tcl/Tk. So, AFAIK, only SpecRuby (see RAA) presently is suitable for doing 
Ruby/Tk. SpecRuby does use drag-and-drop for placing widgets, contrary to 
a mistaken remark I made concerning Tk much earlier this year. FWIW, 
AFAIK, most of SpecRuby works, but I have not tried to do anything 
non-trivial with it yet. As for loose ends, I never finished up the 
automatic scrollbar hookup feature, and there are minor work-around issues 
because Ruby toggled the cases in some of the Tk method names.

Since Glade generates and intermediate XML GUI representation, no 
conversion of Glade was necessary for generating Ruby/GTK GUIs. Beyond the 
fact that several widgets are missing from Ruby/GTK, I'm not sure what 
additional features (if any) are omitted by the script that processes the 
parsed XML into Ruby/GTK code. (There are a few other GTK GUI builders, 
but I don't know their current status or following. AFAIK, Glade is still 
the leading one.)

So Tk and GTK are (presently) ahead of wxWindows and FOX when it comes to 
GUI-based GUI-builders that actually generate Ruby code. 

Apart from *potential* portability issues (that, if real, will presumably 
be solved by GTK 2.0), I think Glade has a powerful long term advantage 
over SpecRuby simply because it has been (and will be) the beneficiary of 
continuing development and support, whereas SpecRuby's parent, SpecTcl, 
was abandoned years ago, with the only subsequent developments being the 
added capabilities to generate Perl, Python, and Ruby. (Although they 
don't support Ruby yet, FOX and wxWindows certainly *potentially* have 
these sorts of advantages.)

Because (AFAIK) Glade aimed at extensibility and flexibility from the 
beginning, and because of the GTK 2.0 aim of adding fewer but much higher 
powered widgets, I wouldn't be surprised if Glade were to eventually make 
if feasible (if it doesn't already have this capability) to relatively 
easily implement extensions for "drag-and-drop database query thingies" 
(given the Gnome project's ambitions).

The SourceNavigator example is an impressive demo of Tk's capabilities, 
but the sort of flexible, configurable, *easily* extensible middle-level 
framework of infrastructure tools to facilitate repeat performances 
without considerable resources seems to be lacking. (Please excuse the 
vague buzzword dump.)  SpecPerl is widely used for lots of modest-scale, 
handy "Do it now!" sorts of utility GUI applications, but this has not (in 
any major way) feed back into the development of SpecPerl, Perl/Tk, or 
Tcl/Tk, AFAIK. So I don't see how Ruby/Tk can (realistically) hope to do 
any better in this regard. I think there is a pretty big niche for 
Ruby/Tk, but it is also one that lacks the sort of growth/migration path 
needed to get to the world of Visual Basic (generically speaking), where 
Ruby's "greater simplicity in the midst of complexity" might be able to 
eventually produce productivity-boosting results and ease-of-use gains 
that are comparable to that of going from K&R C/X11 to Perl/Tk. 

Conrad Schneiker
(This note is unofficial and subject to improvement without notice.)