From: Charles Hixson <charleshixsn@...>
Date: 2000-11-17T02:40:01+09:00
Subject: [ruby-talk:6399] Re: Thoughts on a Ruby browser

Conrad Schneiker/Austin/Contr/IBM wrote:

> Charles Hixson wrote:
>
> # hal9000@hypermetrics.com wrote:
> ...
> # A GUI builder is a really nice feature in an IDE, but is sufficiently
> # complex that it probably isn't a good choice for inclusion in the first
> # iteration.  A later iteration should allow the GUI to be built, but
> perhaps
> # not allow the GUI to be rebuilt after the code has been modified.  How
> to
> # deal with that seems a more difficult topic best saved for later.
>
> Well, if you were using GTK, then you could use Glade (the GTK GUI-based
> GUI builder) in the mean time. And there are already usable Ruby bindings
> to GTK. (This is still a work in progress, but AFAIK, the general GUI
> capabilities of Ruby/GTK probably already significantly exceeds that of
> Ruby/Tk.) This makes it possible to use the output of Glade to generate
> Ruby/GTK programs.
>
> Also, when it comes to incorporating a GUI builder into the IDE, you could
> use a trick that almost all of the Tcl/Tk GUI builders use, which is to
> specify the GUI in terms of an icon-decorated tree structure of widgets
> (that looks somewhat similar to a directory tree in a MS Windows file
> browser) rather than to use the actual physical display layout. So you can
> still do drag-and-drop construction and modification, but you work on
> structural schematic diagrams of the GUI, rather than the target run-time
> display image of the GUI.
>
> Conrad Schneiker
> (This note is unofficial and subject to improvement without notice.)

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.

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).

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.  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.

-- (c) Charles Hixson
--  Addition of advertisements or hyperlinks to products specifically
prohibited