In article <OF3B13E357.43E0558D-ON852569BC.0005EBC2 / raleigh.ibm.com>,
Conrad Schneiker <schneik / us.ibm.com> wrote:
			.
			.
			.
>However, in anticipation of a "Which Ruby/GUI should I use?" FAQ entry 
>(which I currently guess will very likely at least include Tk, FOX, and 
>GTK+ 2.0 by this time next year), do you happen to know off-hand what are 
>regarded as the most serious Tk drawbacks for non-simple applications, in 
>addition to not having as many (built-in, out of the box) widgets as most 
>people nowadays seem to want and expect? 
			.
			.
			.
Mr. Tilly has mentioned its reliance on events rather
than threads for concurrency.  I regard threading as
so hazardous for the majority of developers that I
consider that a wash, but it's at least an issue for
serious GUI applications.

There are "native" issues.  Swing generally takes the
heavy-duty route, and at least has a framework for
anti-aliasing and other font matters; Tk usually takes
a lighter-weight approach, and hits limits.  The Win*
implementation of Tk has a lot of Unixy-looking stuff
running around, some of which definitely constrain
performance.  On the other hand, I have a lot of hope
that the TkGS project will slash whole platoons of
"native" whining.

Lots of complaints about Tk for big, serious stuff
are really about (bare) Tcl.  Tk itself is OOable,
although not with the sophistication of Java.  Perfor-
mance is generally not worth complaining about in a
world that accepts Word, Motif, ...

There are doubtless big, serious structural problems
I'm forgetting tonight.  I'll return to this topic
later.
-- 

Cameron Laird <claird / NeoSoft.com>
Business:  http://www.Phaseit.net
Personal:  http://starbase.neosoft.com/~claird/home.html