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

In article <[e-mail]>,
Conrad Schneiker <[e-mail]> wrote:
			.
			.
			.
>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 
Thanks, by the way, for the privilege of
joining in this serious discussion.  It
feels good to work with folks wrestling
with real issues.

You're right, of course, that the target
needs to be Ruby/Tk.
			.
			.
			.
>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.)
Glade has enormous potential behind it--
all sorts of forces have allied behind
GNOME/GTK+/Glade.  My impression is that
GTK+ stuff, in general, does more "in the
lab" than is generally realized, but that
it also has more rough edges in the field.
GTK+ answers *everything*, IF you're the
one developer who has it working properly
in a particular configuration.  I find
GTK+ more difficult, right now, to get
right, though, in porting, reconfiguration,
and so on.  GNOME people are very energetic
and enthusiastic, and 2.0 will be a great
advance, I expect.  For right now, I prefer
to rely on Tk for my daily work, and several
of the other toolkits also have a lot to
recommend them.

Also, I want to emphasize that "SpecTcl was
abandoned years ago" shouldn't be regarded
as conclusive.  So was Tix (a popular Tk
widget extension, roughly)--but it was just
revived!  The same could well happen with
SpecTcl.  This is *particularly* true now
<URL:http://www.zdnet.com/devhead/stories/articles/0,4413,2652185,00.html>
with Tcl in so much flux.  Tk is now in an
entirely different position than a year ago,
and far, FAR more open to contributions from
*all* its users (Tkinter, Ruby/Tk, TkLua, ...)
than ever before.  It's not like the old days,
where the Tk maintainers only conversed in
Tcl.
			.
			.
			.
>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, 
Excused.  Maybe so.  Probably so.  The one
point I'll add is that the SourceNavigator
people are still with us, and are quite
accessible (see, for example,
<URL:http://gamelan.earthweb.com/earthweb/cda/dlink.resource-jhtml.72.1082.|repository||softwaredev|content|article|2000|11|07|SDlairddejong|SDlairddejong~xml.41.jhtml?cda=true>).  There's a good history
of people stumbling upon Tk, using it to build
something useful quickly, and finding that it
takes them farther than they expected.  Tk
seems to have hit a "sweet spot" for lightweight
			.
			.
			.
>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. 
I understand the point.  I find it a difficult
one to analyze with confidence.
			.
			.
			.
-- 

Cameron Laird <[e-mail]>
Business:  http://www.Phaseit.net
Personal:  http://starbase.neosoft.com/~claird/home.html