[ruby-talk:6384] Re: Thoughts on a Ruby browser

Charles Hixson wrote:

# [e-mail] wrote:
# 
# > 2. I do favor the possibility of a web-based browser. In fact, I
# > wouldn't mind if it was *truly* web-based, i.e., you could look at
# > code running on a remote machine as long as it had an embedded web
# > server.
# 
# That might have it's points, but is probably not a really good idea.
# Better would be a good interface with, say, Mozilla.  Ruby is really 
nice,
# but it is slow when compared to good native compiled code.
# 
# > 3. I do also favor the possibilty of a "native" GUI, whether your
# > desktop of choice is Win32 or Linux KDE. In a case like this, I
# > would prefer an MDI interface, as nonmodal as possible.
# 
# This should also be kept separate from the core of Ruby.  Ruby should be
# minimalizeable, as if for embedding.  The extensions should be managed 
via
# libraries to the greatest extent possible.  That said, YES!!  What might 
be
# looked at would be a wrapper around GTK.  Or, perhaps a wrapper around 
CLX
# (Borland has just announced that CLX will be optionally GPL, and if this 
is
# true on both Windows and Linux, then it !might! be a better choice). And
# of course there is TCL.

OK. 

These things raise some interesting questions about trade-offs, which in 
turn concern priorities for this project. Dave originally suggested 
something along these lines as a way of winning Ruby converts. On the 
other hand, there are significant trade-offs involving the amount of 
effort and time it takes and the level of performance and quality that can 
be attained versus the range of platforms that are initially supported. 
Would most people prefer maximizing the number of new Ruby users 
(especially keeping in mind the long term compounded interest effects of 
larger initial growth rates) even if this meant only initially supporting 
(say) Unix/Linux and Windows?

I've seen assurances (sorry, I don't have a reference handy) that the 
quality of Windows GTK ports was going to improve substantially early next 
year, with (IIRC) the implication that you could base serious projects on 
it. And I think it is safe to assume that GTK already works pretty well on 
the leading Unix brands, and that this situation will continue to improve. 
I don't know what the situation for Mac OS users is; although I would 
expect the prospects to be much better for users of the new OS, although 
AFAIK, they are a small minority at present. So here is one place the 
previously-mentioned sorts of trade-offs (probably) shows up (to some 
seriously significant degree). And likewise for still other platforms.

# > 10. I'd like the capability to click on a standard identifier and get
# > documentation on it -- different levels of documentation, beginning
# > with just, for example, the "prototype" of a method. I'd like to click
# > on the user-defined stuff and get information about it -- where is it
# > first defined, where is it used, etc.
# 
# This might be a good choice for the first round, if it's easy enough to
# do.  It could make learning the language much faster, and would be 
helpful
# even later.

That is a very good point and should be a primary objective. 

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