Re: Command interfaces like the Lisp Machine

This sounds exciting to me. Even within a terminal, controlling the output channel is a good thing. It could allow the tools a better way to separate compiler noise from warnings and errors. The compiler metrics are interesting to some, but not really useful to me during development.

The ability to have deft or something watch for changes and recompile and/or run tests like sbt or guard would be fantastic too.

On Mar 11, 2014 8:23 AM, Bruce Mitchener <[email protected]> wrote:
Lately, prom has been developing a library called "command-interface" which is now available here:

    https://github.com/dylan-lang/command-interface/

I've been using it in a new build tool that I call "deft" or "Dylan Environment For Tools". Deft provides things like a package description and will know how to do builds with just "deft build" and tests with "deft test" and so on.  This should be a big simplification for people learning or using Dylan.

But prom and I are talking a lot about extending this system to support richer interaction models, not just text-based.

This is something that Lisp Machine did and that CLIM / McCLIM did as well as can be seen in this screenshot:

    http://dishevelled.net/shots/mcclim-listener.png

What we'd like to pick up is the ability to have the output presented that vary based on the capabilities of the terminal / application:


  *   When printing to a dumb terminal, output would be very basic.
  *   When printing to a VT102 or better terminal, things like progress bars and such might be displayed.  Color can be used.
  *   When running within a richer application, mouse interaction can occur, graphics can be shown, etc.

How might we use this?


  *   When running a build, we might show a progress bar as it goes through the files in a project when we can, and keep the warnings scrolling above that.
  *   When showing a class hierarchy, in a rich application, we'd be able to have mouse actions attached to classes to further interact with them. We'd also be able to show hierarchies graphically and be able to interact with the graph.

I think a starting approach might be to have data models that commands can interact with and views or presentations of that data model that can be displayed. This makes it a pretty classic MVC model.

A command needs to be able to start the presentation prior to the command completing because many commands are long-running (builds, tests, etc).  I think we can define abstract classes for the presentations and then let the display / terminal create the right per-display class that is needed.

We'd also have gadgets or widgets which represent the basic things that a UI is built with (much like DUIM). This would hopefully make it fairly easy to go about creating a presentation on top of a basic set of widgets. Perhaps we could even use parts of DUIM here? I'm not sure.

The goal is that it should be easy to create better text UI than just spewing output to a stream and eventually, it should be easy to have this UI upgrade to richer capabilities (HTML, native widgets, etc).

Thoughts?

 - Bruce

_______________________________________________
hackers mailing list
[email protected]
https://lists.opendylan.org/mailman/listinfo/hackers