From: Charles Hixson Date: 2000-11-15T03:10:06+09:00 Subject: [ruby-talk:6366] Re: Thoughts on a Ruby browser hal9000@hypermetrics.com wrote: > ... > 1. Yes, we do have to have SOME kind of interface. But let's keep it > as independent from the core functionality as we can. I agree totally. But this isn't a real problem for Ruby. (A benefit of a highly dynamic language!) > 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. > 4. I'm not an emacs weenie, but numerous people I respect are. I > favor a way to hook the browser into emacs (and whatever other > editors are powerful enough). Many people like emacs, but most descriptions that I've heard have been discouraging. Still, I see no reason why an IDE shouldn't allow people to choose an alternate editor. > 5. No matter the interface, I am a big believer in "collapse and > hide" features. For example, when looking at code, I would like to > be able to hide the embedded docs. I would like only a very shy, > unobtrusive hint that the docs are even there. Yet on the other > hand, I would like a feature that says, "Collect ALL the embedded > docs and show them to me." I would like to be able to view a single class or a single routine in detail. And also to spread it all out. But perhaps this wouldn't be a first round feature. > ... > 7. I want the browser to remember every detail of the state I was > in at the end of my last session. This can be nice, and shouldn't be hard. But could easily be a second iteration feature. > 8. Possibly allow changing of syntax to equivalent forms by a simple > keystroke combination or button click. (Hmm, I'll change that for-loop > to a .each, and I'll change these braces to a do-end...) Does anyone > remember the Alice Pascal compiler from long ago (1985)? In some ways > it was very neat... it had a syntax-directed editor that made it nearly > impossible to make a syntax error, and easy to make changes of the > sort I just mentioned. Unfortunately, it also made it rather difficult > to type in even a correct program... Think carefully about this one. This may be more complex than the gain would justify. Unless you can think of an easy way to write it? (I'm just getting started in Ruby, though I *do* have strong opinions about IDEs.) > 9. I favor a flexible and customizable interface. Let me create my own > macros (in Ruby, of course), assign icons to them, and add them to the > toolbar. Another good feature that should be a second round feature. Remember KISS! > 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. > 11. I wish (though this is not possible in Ruby as it is) that we could > associate a comment specifically with the piece of code it belongs > with. I have often thought that perhaps program text should advance to > the point that it was more like a word-processing document, with a > browser-like tool required in order to use it... that is a break with > tradition, and millions would disagree with me, though. Umnh... Possible? Why not? If we are creating an IDE, then we can expect that there will be a project file. The project file could hold this kind of comment. But remember to keep the program files separate from the extra stuff. Embedding this would be like embedding the colors used for syntax highlighting. Possible, but an idea that would make the compiler much more complex. > Just a few thoughts. > > Hal > > -- > Hal Fulton > > Sent via Deja.com http://www.deja.com/ > Before you buy. I think of an IDE as basically an index of what files are needed combined with a syntax aware editor. The editor is not necessarily perfectly syntax aware, though irb demonstrates that this is not unreasonable for Ruby, so I think that it should be perfectly syntax aware. Really nice is if it does keyword and special thing highlighting (special colors for strings, comments, etc.) Also nice is if it recognizes already defined terms (perhaps not in the first round?). It stores this info in a project file, which is basically a directory of the files needed to build the project, though other information can be stored there also. And it should allow test executions of the work in progress. I don't really like it to evaluate each line as it is typed. Ruby Window is a much better example (but it would be nice if it didn't lock up on program errors). 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. -- (c) Charles Hixson -- Addition of advertisements or hyperlinks to products specifically prohibited