From: Conrad Schneiker/Austin/Contr/IBM Date: 2000-11-16T04:38:32+09:00 Subject: [ruby-talk:6384] Re: Thoughts on a Ruby browser Charles Hixson wrote: # hal9000@hypermetrics.com 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.)