[Openmcl-devel] GUI element needs

Hamilton Link hamlink at cs.unm.edu
Mon Aug 8 23:00:13 UTC 2005

OK, intrepid readers, here's what bubbled to the top of the list.  Only 
five people actually participated, but possibly people will chime into 
the discussion thread of this email on top of that.

Top 1:
> Editor (2x)
> Listener
> Profiler
> **** Bundle Builder
> VIM integration with editor

Top 5:
> Editor (5x)
> ** Backtrace (5x)
> Listener (3x)
> ** Stepper (3x)
> **** Bundle Builder (3x)
> Inspector (2x)
> ** Trace (2x)
> *** Documentation manager (2x)
> Apropos Dialog
> * Thread viewer
> Profiler
> A ham sandwich (yes, really)

To me a listener is what *makes* a lisp environment and I'd have 
difficulty envisioning a lisp development environment without one, but 
it only made #1 in my list, and was tied for 3rd in total votes for 
top-five placement.  Go figure.
    Everyone seems to want an integrated editor, although the emacs/vi 
thing has now reared its ugly head (possibly inevitable with two or 
more users).  I don't know if Hemlock has a vi mode or not, but it 
wouldn't surprise me...
    I think the top 5 top-five rated things are all sensible, but the 
stepper and bundle builder are not highly supported right now (Although 
I might use a stepper I'm not in the habit of doing so... I'm not sure 
openmcl even has a working stepper... did that ever make it in from 
    Two things I had in my top five (inspector and apropos) aren't as 
much in the running... I suppose I'll have to implement them myself 
then, but I guess it's good I put out the survey and didn't trust my 
personal preferences.

Anyway... the cocoa IDE has a backtrace, editor, and listener, and as 
these were all in high demand I would encourage everyone to bang on the 
cocoa IDE and send feedback to the list (bug reports, feature requests, 
change suggestions, questions on how to change the keybindings, etc.), 
and I'd personally say to the degree people try to use the IDE it might 
make sense for GB or Alex or I to spend time tuning them.
    Bundle builder integration... now that's an interesting thought.  
Possibly given the prospect that bundles will run under more than the 
version of the OS they're compiled for will encourage the friendly 
folks that brought us Bosco to have a go at full-blown incorporation of 
Bosco with openmcl at the level of
(progn (require "COCOA")
        (require "BOSCO")
if that's possible.  Also maybe GB can at least remind us what the 
state of the stepper is in openmcl (even if "absent").

Here are the rest of the ratings:

Above ham sandwich but not in top 5:
> Bundle Builder (2x)
> Profiler (2x)
> Stepper
> Listener
> Find-in-Files Dialog
> Thread Viewer
> Class Hierarchy Viewer
> Package Viewer
> Apropos Dialog

Below ham sandwich:
> Class Hierarchy Viewer (4x)
> Thread Viewer (3x)
> Hotkey Bindings Dialog (3x)
> GnuStep Compatability (3x)
> Package Viewer (2x)
> Find-in-Files Dialog (2x)
> Inspector (2x)
> Editor
> Backtrace
> Stepper
> Listener
> Bundle Builder
> Apropos Dialog

* The comment from DLR was "I'm assuming you're talking about something 
advanced than :proc, as opposed to a gui for viewing threads) -
something that would be nice is a way to interrupt a thread given its
process number, such that you could do a :b to find out where it
currently was in execution. In theory, finding it in the current-process
list and sending it an interrupt with a call to (read), and then
interrupting the read should do this, but I haven't tested it yet."

** Two people called Step, Trace, and Backtrace put together a 
"Debugger (Step, Trace, Stack viewer)" which I took to mean those three 
somewhat distinct bits of functionality were all important to them.  A 
useful question for the group is whether or not those three bits of 
functionality make sense to have together and how that would look if 
so, but that's really a separate question.

*** Lisp docs and external class descriptions integrated with the editor

**** I lumped "Cocoa Application Builder" and "Bundle Manager" in with 
"Bundle Builder"

More information about the Openmcl-devel mailing list