Command interfaces like the Lisp Machine

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