My opinion is that ease-of-installation is paramount here.  Asking
people to install
Mozilla just to develop ruby may not be acceptable.

In every Linux distribution, Tcl/Tk is already installed and Mozilla is
not (unfortunately).
On Windows systems, Tk may already be installed because of its use in
other toolkits --
also the Windows version of Tk has stabilized for some time.  I would
just use Tk there
too.

If the class browser generated static html pages (like Javadoc) then one
could use
ANY browser to navigate the hierarchy.  Perhaps rdtool could do this for
the
non-dynamic class/api document generation.

/<
Keith Weinberg


Conrad Schneiker/Austin/Contr/IBM wrote:
> 
> Charles Hixson writes:
> 
> # Glade is a reasonable choice, but my experience has been that unless you
> are
> # targeting C, you may have configuration problems.  This even includes
> C++.
> # Also, the times that I've tried to install it on a Win95 system I
> haven't been
> # successful.  I presume that this will improve, but it needs to be
> watched!
> #
> # One real benefit of choosing Glade is that it is already designed to
> emit code
> # destined for inclusion in another language.  One drawback is the
> difficulty of
> # placing items with a fixed size in a fixed position.  Or in a relative
> # position based on where I put it.  Dividing the screen into rows and
> columns
> # before the design is final is ... I've often ended up starting from
> scratch.
> # But it's available now, and, at least on Linux, it works now.  That's a
> really
> # big plus.
> #
> # OTOH, it might be nice to build it based around XML as I understand KDE2
> is
> # doing.  That source code is also available, though it might be quite a
> bit
> # less portable.
> 
> Isn't XML still the intermediate/persistent data format for Glade? IIRC,
> many months ago, I had to fetch some Ruby/XML stuff in order to go from
> Glade to Ruby/GTK.
> 
> # Or the Mozilla Composer might address the problem. (If we were going to
> be
> # using Mozilla anyway, why not use it to address GUI building?)  A
> Mozilla
> # based solution would have the advantage that a huge amount of
> development was
> # on-going, that it's already cross-platform, and that it already handles
> # printing (solving another thorny issue).
> 
> Good points, although Tcl/Tk 8.4 (somewhere around the alpha-to-beta
> transition stage) is supposed to provide printing support. Not to mention
> that it makes on line documentation much more readable and uniform with
> much less effort in many cases, and good interactive documentation is
> certainly an important factor here.
> 
> # So my evaluation of the trade-offs (based on only a view from a
> distance) says
> # that the first thing to look at would be a Mozilla based solution.
> 
> Do others generally agree?
> 
> # This might
> # cause a huge application, but most of it would be in things that were
> already
> # present on many (most?) users machines, and perhaps the code could be
> shared.
> 
> And we could start by sharing the Komodo code
> (http://www.activestate.com/Products/Komodo/Download_Komodo.html).
> 
> Is anyone up to doing the Ruby XPCOM bindings for mozilla?
> 
> If not, we may want to use Ruby/Tk for the time being until we attract a
> larger base of developers. This has the big advantage that a Ruby/Tk IDE
> could probably be included as part of the (roughly speaking) "standard"
> Ruby distributions without major bloat concerns, since Ruby/Tk is already
> present.
> 
> Conrad Schneiker
> (This note is unofficial and subject to improvement without notice.)